A founder asked me last year to build him a CRM. Three meetings in, it turned out he wanted two things his current CRM already did, plus one report nobody had thought to export. We did not build him anything. That is the part of custom software work most people skip: deciding whether to build at all.
Custom software gets sold as a competitive edge, a strategic asset, a moat. Sometimes it is exactly that. More often it is a liability you signed up for without reading the maintenance clause. What follows is a builder’s view of when a custom build is worth it, how one actually runs, and the ways these projects quietly come apart. It sits alongside our wider writing on agentic AI and how we build software at PTAS.
What custom software actually buys you
Custom software is an application built around your processes instead of a product you adapt your processes to. That is the whole definition. Everything after that is detail.
What you are really buying is fit and ownership. The software does the thing your business does, in the order your business does it, and you decide what changes next. A packaged product hands you someone else’s idea of how the work should go, which is fine right up until your work stops looking like everyone else’s.
The catch is that fit and ownership are also the bill. You own the bugs. You own the upgrades. You own the decision, two years from now, about whether it is still worth paying for. None of that shows up in the demo.
When off-the-shelf is the right call
Most of the time, buy. I say that as someone who builds software for a living. If a mature product does eighty percent of what you need and you can live with the other twenty, buying it will be cheaper and faster than anything I can build you, and it will keep getting better while you sleep, because someone else is paying for that.
Custom starts to make sense in a few specific situations. When the process is the thing you compete on and you would rather it did not look like your competitor’s. When you have honestly tried the products and they do not fit, and I mean “it cannot model how we actually work,” not “the buttons are ugly.” When a core process is currently held together by a spreadsheet and three browser tabs because nothing on the market joins them up. Those are real reasons. “We want something that is ours” usually is not.
How a build actually goes
People picture custom software as a long stretch of coding. The coding is the easy part. Most projects live or die in the weeks on either side of it. The shape is almost always the same four phases.
Discovery
Work out what the software has to do and how you’ll know it worked. Most failures trace straight back to skipping this.
Design
Decide the shape: screens, data model, how it talks to your other systems. The expensive mistakes are made or avoided here.
Build
Ship working slices every couple of weeks so you react to real screens instead of a document full of promises.
Run
It keeps needing patches, updates, and small changes after launch. Budget for that or regret it later.
Discovery, or working out what you actually need
This is where someone sits with your team and figures out what the software has to do, which is harder than it sounds, because people describe the workaround, not the goal. Someone will tell you they need a button that exports a report. What they need is to stop being asked the question that report answers. Those are different builds.
What the first two weeks look like
We map the process as it really runs, not as the org chart says it runs. We watch where work piles up and where people quietly fix things by hand at five o’clock. We write down what “done” means and how we will know the new system beats the old one. If we cannot agree on that last part, we stop, because there is no sense building toward a finish line nobody can point to.
Design and architecture
Once we know what it does, we decide how it is shaped: the screens, the data model, how it connects to your other systems, where the security has to be strict. A data model that fits the business is invisible. One that does not will make every future change feel like surgery, and you will be paying for that long after launch day.
Building it
Now the part everyone pictures. We build in small slices and put working software in front of you every couple of weeks, because the alternative, vanishing for six months and reappearing with a finished product, is how you build the wrong thing very thoroughly.
Why we ship in slices
Feedback on something you can click beats feedback on a document every time. You will open a real screen and realise the field you swore was critical is one you never touch, and the thing you forgot to mention is the thing you use forty times a day. Better to learn that in week three than month five.
A quick example
On one finance build, the client was certain they needed an approval matrix with five tiers. We shipped a two-tier version first. After a month of real use, nobody had ever reached tiers three through five, so we deleted them. That was three weeks of work we did not have to do, and we only found it because they were using the thing, not reading about it.
Testing, launch, and the part nobody budgets for
Testing is not a phase you bolt on at the end. It runs the whole way through. There is a stretch near launch where you check the software holds up under real load and the weird edge cases people only hit in production. Then the launch itself, which for anything replacing an existing system means migrating data without losing a row, training people who liked the old way, and rolling out slowly enough that a problem stays a hiccup. Then the part nobody budgets for: it keeps needing attention after it ships.
Some honest numbers
I am wary of the statistics that get quoted in posts like this. “Thirty to fifty percent efficiency gains” tells you nothing about your situation. Here is what we actually see across builds, with the obvious caveat that yours will differ.
Ranges PTAS sees across real projects, not industry benchmarks. Yours depend on scope and how many systems the software has to talk to.
The ways these projects go wrong
When a build fails, it is rarely the code.
Scope creep, the slow kind. Not a sudden pile of new demands, but a steady drift of “while you’re in there, can you also…”. Each request is reasonable on its own. Together they double the timeline. Agree up front how changes get decided, and be willing to say no out loud.
Pretending maintenance is optional. Software is not a building you finish and walk away from. It needs patches, dependency updates, and small fixes for as long as you run it. Teams that do not plan for this end up with code nobody dares touch, which is how a six-figure asset turns into a liability in three years.
Buying on price alone. The cheapest quote usually wins by leaving things out: tests, documentation, the boring work that keeps software safe to change later. You pay for those eventually, with interest, and the bill tends to arrive at the worst possible moment.
So, should you build?
If a product on the market does the job, buy it and spend your energy somewhere it matters more. If the process is core to how you compete and nothing fits, or you have outgrown the spreadsheet-and-tabs setup holding a critical workflow together, a build can pay for itself many times over. The honest version is that it is a long commitment, not a purchase, and the teams who treat it that way are the ones still happy with their software three years later.
If you are not sure which side of that line you sit on, that is worth a conversation before it is worth a quote. Half the scoping calls we take end with us telling someone they do not need us yet. That is a perfectly good outcome.