Custom Software: Who Should Build Your Portal, Dashboard or Internal Tool.

• YesLyfework

  A portal, dashboard, dispatch tool, field app or quoting tool built around the way your business runs, then kept running month to month by the same team that can run your site and marketing. The code and the data are yours outright.

• Usually notMarketing Agency

  Marketing agencies are built to run ads, social and campaigns, and many do that well. Writing software is a different trade, so a portal or an internal tool usually gets passed to an outside developer or left off the plan.

• SometimesFreelancer

  Some freelancers are skilled developers who can build a portal or an internal tool, and build it well. Many are web designers who build sites, not software. After launch, fixes, changes and hosting are usually yours to arrange.

• Usually notSEO Company

  An SEO company knows how to get your pages found and ranked. Building the software your team runs the business on is a different job, and it usually sits outside what an SEO company offers.

• Usually notDIY Builder

  A DIY builder like Wix or Squarespace is made for websites, and its app add-ons can stretch it a little. A portal, dispatch or quoting tool built around your process is beyond what a builder does, so owners often end up stitching apps and spreadsheets together.

How we picked these: Picked from what decides whether a custom tool saves your team time or becomes one more thing nobody opens.

1. Built from how your team works today

   A good build starts by mapping the real process: who touches the job, in what order, and where it stalls. Software designed from a guess gets worked around.

2. One costly problem solved first

   Start with the task that eats the most hours or loses the most money, like quoting or dispatch. Build that, use it for real, then decide what comes next.

3. Works on a phone in the field

   If your crew uses it on a job site, it has to load fast on a phone, take photos and sign-offs, and still make sense with gloves on and weak signal.

4. Connected to the tools you keep

   Your calendar, customer records, payments and accounting should feed it and hear back from it, so nobody types the same job in twice.

5. A person can always override it

   Dispatch that routes jobs on its own, or a quote that prices itself, still needs someone who can step in and change it when the situation calls for it.

6. The code and the data in your name

   The code, the data and the accounts it runs on should belong to your business, in writing, so you can take it to another developer if you ever need to.

7. Someone keeps it running after launch

   Phones update, connected tools change and your process grows. Software needs fixes and small changes for as long as you use it, so decide who handles them before the build starts.

• Who owns the code, the data and the accounts it runs on?
• Will you map how my team works before you design anything?
• What would you build first, and why that piece?
• Does it connect to my calendar, customer records, payments and accounting?
• Can my crew use it on a phone in the field?
• Who fixes it and makes changes after launch, and how fast?
• Can I see working software you've built, rather than mockups?
• If we part ways, what do I get handed over, and in what form?

1. 1
   List the workarounds your team lives with

   The spreadsheet everyone edits, the texts that stand in for a dispatch board, the quote rebuilt by hand every time. Each one is a candidate.

2. 2
   Put a cost on each one

   Hours a week, jobs that slip, mistakes that mean a second trip. The one that costs the most is usually the first build.

3. 3
   Check what an existing app can do first

   If an app already on the market fits your process with small changes, use it. Custom software earns its place when nothing fits the way you work.

4. 4
   Choose who builds it and who runs it

   A skilled freelancer can build it if someone on your side will run it after launch. If you want it built and kept running for you, choose a team that stays.