BetterCloud puts the average company at 118 SaaS apps in 2026, up from 106 the year before. Search for customized software examples and you get the same short list every time: Uber's dispatch engine, Netflix's recommendation system, Amazon's warehouse robotics, a hospital's electronic health record. All of them are real custom software. None of them helps much when you're deciding whether to build, because each one came out of a company with thousands of engineers and a problem no vendor could have sold them. The example that matters to a buyer is the 119th app: the one that encodes a workflow none of the other 118 handle.
After 11 years of building software at EltexSoft, my position is narrow. Customized software is worth what it costs in one situation only: when the logic you're customizing is the thing your customers pay for. Authentication, billing, email, CRM, analytics dashboards and admin tables should be bought or taken from open source. A good custom build is a small, very specific core with integration code around it. To read any list of customized software examples usefully, ask of each one which part is the core and which part is commodity. The questions below decide that, in the order I'd ask them.
What the Famous Examples Actually Show
Even the famous examples are mostly bought parts. Uber sent its early rider text messages through Twilio. What it built itself was matching and pricing, the two things that decided whether a car showed up and whether the trip made money. The pattern holds at every scale. The custom portion is small and valuable. The rest is plumbing that someone else maintains better and cheaper.
Here is an example closer to the size most buyers work at. Since 2016 we have been the engineering partner for MyFlyRight, a platform for EU air-passenger compensation claims that we built from scratch on React, Laravel and PostgreSQL. The part no SaaS product could supply is the eligibility logic. Under EU261, compensation is €250, €400 or €600 depending on flight distance bands of 1,500 and 3,500 kilometres, how late the flight arrived, and whether the airline can claim extraordinary circumstances. A form builder can collect those inputs. It can't decide the claim. The platform has since processed more than a million claims, and every one of them passed through that core logic, not through the login screen or the payment integration.
The Buyer's Checklist
1. Is the Custom Part the Thing Your Customers Pay For?
This question kills more custom projects than any other, and it should. If the workflow you want to customize is internal (expense approvals, a sales pipeline, a ticketing queue), some vendor has already spent ten years on it, and you'll spend your first year rebuilding their v1. The builds that pay back have a sentence that finishes "our customers choose us because we can..." and the next few words describe logic, rules or data nobody sells. A claims decision, a pricing model, a training plan generated from someone's race history, marketplace matching rules. If the sentence finishes with "because our dashboard is nicer," configure a SaaS product and spend the budget somewhere else.
2. Can You List What You Will Not Build?
The most reliable sign of a custom project that will overrun is a scope where everything is custom. For Snapwire we provided 10 engineers inside a 30-person engineering organisation for two and a half years. The marketplace payouts ran on Stripe Connect, search ran on Elasticsearch, and hosting ran on AWS. Nobody proposed rebuilding any of them, and that's why the engineering hours went into the marketplace itself. A buyer's brief should have a do-not-build list as long as the build list: identity, payments, notifications, file storage, reporting. Each item you move from custom to integrated takes weeks out of the estimate and removes a system you'd otherwise maintain for years.
3. What Is the Smallest Version That Earns Money?
Meal4U came to us as a stalled build that the previous team had failed to deliver. The fix was a scoping discipline, not a technology change. We spent a week taking the scope apart and re-estimated it about ten times, cutting 30 to 50 percent on each pass until we reached the smallest product that could ship. The cuts compound: three passes at 40 percent leave about a fifth of the original scope. Our estimate bands show why this matters: an MVP typically runs $40,000 to $100,000, a SaaS platform $60,000 to $150,000, and a two-sided marketplace $80,000 to $200,000. Where a project falls inside its band depends mostly on how many roles, integrations and edge cases survive the scoping week. A buyer who has done that cutting before the first sprint pays near the bottom of the band. One who does it in month five pays near the top and ships later.
4. Is the Spec Detailed Enough to Argue With?
HeyTutor's founders came to us in 2016 with a one-page spec. Before building, we extended it to 40 pages. The extra 39 pages held no padding. They held the questions a one-pager leaves open: what happens when a tutor cancels, who gets refunded and when, which roles can see which records. Every one of those questions gets answered eventually. It costs a conversation if it's answered in the spec and a rebuild if it's answered in production. A custom build is only as specific as its written requirements, and a vendor who quotes a fixed price off one page has either padded the number or plans to fill in the gaps with change requests.
5. Does a Date Depend on It, and Can the Existing Code Meet It?
Plenty of custom projects start from an inherited codebase, and inheriting code changes the risk more than any feature list does. For Nautical Commerce we picked up a codebase that was a year old and delivered against a 90-day go-live for a marketplace-as-a-service model. A date like that is only credible if the first days go on reading the existing code: what is sound, what gets wrapped, what gets replaced. A buyer with a hard date should ask any vendor what they'll do with the current code before they talk about new features. A vendor who proposes a full rewrite against a 90-day deadline has told you something important about the plan.
6. Who Owns It, and Who Runs It in Year Three?
Custom software costs money every year after launch. A reasonable planning figure is 15 to 25 percent of the original build cost per year for maintenance. The number of third-party integrations moves it most, since each one ships its own breaking changes, and so does having a mobile app, because iOS and Android both release a major version every year. On a $120,000 SaaS build, that's $18,000 to $30,000 a year before you add a single feature. Two things keep that figure at the low end. The first is full code ownership: we build on a work-for-hire basis, so the repository belongs to the client from the first commit. The second is code that stays changeable. At EltexSoft every pull request is reviewed by at least one other senior engineer before it merges, including code drafted with AI tools like Claude Code or Cursor. That isn't there for show. Year-three maintenance is cheap when year-one code was read by two people. Our MyFlyRight partnership is now close to ten years old, and the review habit is a large part of why the platform can still take new features.
What a Good Example Looks Like on Paper
Put the six answers together and a customized software example worth copying has a recognisable shape. The core logic is the thing customers pay for. The do-not-build list is explicit, the first release was cut at least three times before a line of code was written, the spec answers the uncomfortable edge cases, any inherited code was assessed before the date was promised, and the owner has budgeted for year three. The famous examples have that shape too, which is the one lesson worth taking from them. The size of Uber's engineering team doesn't transfer to you. The discipline of building only what nobody could sell them does.
This is how we structure engagements at EltexSoft. A free discovery week puts your proposed build through these six questions, so the core and the do-not-build list are on paper before any money changes hands. A paid pilot with no lock-in then tests the riskiest part of that core, followed by two-week sprints with daily standups once the scope has earned it. The next step is to bring us the one workflow you believe none of your 118 apps can handle, and we'll spend the discovery week finding out whether it's true.
Last updated October 6, 2026