When someone asks me to build them a system, the first thing I ask is what they use today. The answer tells me more than any requirements document, because it shows where the current tool stops working and what people are doing to cover the gap: a spreadsheet exported every Friday, a WhatsApp group where orders get confirmed by hand, a person whose half-time job is copying data from one screen to another.
Build custom software when the workflow is strategic, meaning it’s how you compete, and the tool you use today is being held together by workarounds. Buy anything that’s utility, like payroll, accounting, payments or login. For internal panels, forms and prototypes, low-code or a better-configured SaaS is usually enough. A custom build starts at $15K and 6 to 14 weeks, plus maintenance afterwards.
I build software for a living at Softronic, and I still tell people not to build more often than you’d expect. This post is the reasoning behind that.
Three options, not two
The usual framing is “SaaS or custom.” There’s a third path in between, and it’s frequently the cheapest one:
- Buy. Use an off-the-shelf product as it comes. You adapt your process to the tool.
- Assemble. Connect existing tools with low-code and automation: an internal panel in Retool or Appsmith, a base in Airtable, flows in n8n, Make or Zapier, a form in Tally. You get something close to custom without owning a codebase.
- Build. Your own application, your data model, your code, your roadmap. You also own the maintenance, forever.
Is this utility, or is it what makes you different?
Martin Fowler wrote about this years ago as the utility vs strategic dichotomy, and it’s still the most useful filter I know. Utility software is the stuff every company needs and nobody wins by doing better. Fowler’s example is payroll; I’d add accounting, login and sending invoices by email. For utility, you want the cheapest reliable option, which almost always means buying it.
Strategic software is the part of your operation that sets you apart from the competitor down the street. How you quote a job, how you route a delivery, how you match a buyer to a property. That’s where custom starts to make sense, because a generic tool forces you to run your business the way the vendor imagined its average customer.
Most requests I get mix both. The trick is to buy the utility parts and only build the strategic core.
What I’d buy without thinking twice
Authentication, payments, transactional email, payroll and HR, accounting, general project management. There are mature products for all of these, and they handle things you don’t want to own: compliance, fraud, deliverability, tax rules that change every year. If a proposal includes building any of these from scratch, and your business isn’t exactly that, push back.
A CRM for a small sales team also belongs on that list. A generic CRM becomes a problem only when your sales process stops looking like “lead, deal, closed.”
Where low-code is the right answer
I have nothing against low-code. For certain jobs it’s the best option available:
- Internal admin panels over a handful of tables where the workflow is list, filter, edit, save.
- Forms and intake.
- Moving data between SaaS tools: notifications, simple syncs, a report that builds itself.
- A prototype to find out whether anyone wants the thing before you spend real money on it. Tools like Bubble or Lovable can put something clickable in front of users in days.
If the idea doesn’t take off, you found out cheaply.
Signs you’ve outgrown the tool
Whether you’re on a SaaS or on a low-code setup, the symptoms are similar. When I see several of these together, it’s usually time to consider building:
- The workarounds are the system. Exports, manual syncs, webhooks to patch missing features. People are holding the tool together.
- Logic lives in the escape hatches. In low-code, this means most of the important rules sit in custom scripts, plugins or nested visual flows that only one person can read. If that person leaves, nobody can safely change anything.
- You can’t test it. Most platforms have weak or no support for automated tests, so every change is a small gamble.
- You can’t see or tune performance. When a screen takes ten seconds to load and the database belongs to the platform, the only fix available is a bigger plan and a support ticket.
- The price grows with headcount, not value. Per-seat and usage-based pricing is fine when you’re small. At some point you’re paying more every month for the same features.
- You need things the platform wasn’t designed for. Real multi-tenant isolation between your customers, audit trails for a compliance review, data you need to query your own way.
- Leaving has become scary. If you can’t export your data and logic in a usable form, every price change or acquisition is a risk you don’t control.
One or two of these is normal friction. With four or five, you’re paying for a tool plus the people compensating for it.
Why we built Homly instead of adapting a CRM
Softronic has its own product, Homly, a CRM for real-estate agencies, and it came from exactly this kind of decision. Generic CRMs are organized around a sales pipeline. Real-estate work is organized around matching properties to what each client is looking for, and in a general-purpose CRM that matching ends up in custom fields, filters and spreadsheets on the side. The matching was the core of the work, so that was the part worth owning. The rest (scheduling, contracts, messaging) lives on the same platform because it needs to share that data.
It’s the same rule applied to ourselves: build the strategic core, not everything.
How much does custom software cost, compared with the other two?
My published starting point for a custom build is $15K and 6 to 14 weeks, depending on scope. The lower end gets you one core workflow in production that you own. Larger products with integrations, admin tooling and several user roles cost more. Before I give a number, I write the scope down, including what’s explicitly out of it, and the project is then quoted at a fixed price for that scope.
Software isn’t finished when it ships. Operating system releases, API deprecations, security patches in dependencies and certificate renewals keep coming whether you add features or not. That’s why I offer maintenance as a monthly block of hours, starting at $1,400 for 20 hours. When you compare against a SaaS subscription, compare the build plus at least two years of maintenance, not the build alone.
Here are the three paths side by side. The last rows are for your own numbers; the only prices in it are my published ones.
| SaaS (buy) | Low-code (assemble) | Custom (build) | |
|---|---|---|---|
| Who adapts | Your process adapts to the tool | Some of both | The software adapts to your process |
| Good fit | Utility: payroll, accounting, payments, login, a CRM for a small team | Admin panels, forms, syncs between tools, prototypes | The strategic core of how you operate |
| What you own | Your data, if the export works | Data and flows, inside someone else’s platform | Code, data model and roadmap |
| Automated tests | Weak or none for your own setup | Weak or none on most platforms | Yours to write and run |
| Performance | A bigger plan and a support ticket | A bigger plan and a support ticket | You can see it and tune it |
| Cost grows with | Seats and usage | Platform tier, paid plugins, hours keeping automations alive | Scope, then maintenance hours |
| Leaving | Depends on the export | Logic is hard to move out of visual flows | You already own the code |
| Upfront (fill in) | Setup and data migration: $____ | Building the flows, in your hours or a contractor’s: $____ | From $15K and 6 to 14 weeks, fixed price once the scope is written: $____ |
| 24 months (fill in) | Last 12 months’ bill, projected with the headcount you expect, times two: $____ | Platform tier at that volume + plugins + upkeep hours: $____ | Build + 24 months of maintenance (from $1,400 for 20 hours a month): $____ |
The upkeep line in the low-code column is the one that never appears in the budget, so ask whoever maintains the automations how many hours a month they spend on them.
Leaving a platform without a big rewrite
If you’ve already decided to move off a tool, don’t do it in one shot. The approach that works is the strangler fig pattern: build the new system next to the old one and move one workflow at a time.
In practice: document every workflow and business rule in the current setup, pick the one that hurts most (usually the slowest or the one with compliance pressure), build its replacement, and run both in parallel while you verify. Move actively used data in batches and archive the rest. Repeat until nothing depends on the old platform, then cancel it. Each step ships on its own, so you see the benefit early and can stop if the math changes.
Start with a list, not a quote
Before you talk to any developer, write down the three workflows that matter most to your revenue and, next to each one, the workarounds your team uses today. Mark each as utility or strategic. If a strategic one is held together by workarounds, that’s the one worth pricing, and my services page shows how I scope that kind of build.