Where the builds diverge
The divergence happens in the data model, long before it shows up in the interface.
An internal tool can assume one company, one set of rules, one way of naming things. A product cannot assume any of it. Every assumption you bake in for the first user becomes a migration for the second.
This is why the two builds cost differently even when they look identical on screen. The screens are the cheap part. The structure underneath is where the money goes, and the structure is decided by whether strangers will use it.
When an internal tool is the honest answer
Fixing your own operation is a legitimate outcome. It does not need to be a startup.
Plenty of businesses build software to run better, not to sell. Replacing fragmented spreadsheets, giving the team one dashboard, making traceability and costing reliable. These are real, valuable projects with a clear return.
The failure mode is scoping that work as if it were a product. It adds cost, delays the thing you actually needed, and produces a platform with nobody to sell it to.
When it is genuinely a product
If the workflow is common across an industry and nobody has solved it well, that is a product.
Vertical software wins when the industry is underserved by general tools and the operational logic is specific enough that horizontal products cannot reach it. The insight has to be transferable. What works in your business has to work in a business you have never seen.
The test is not whether the software is good. It is whether the next company can be onboarded without you in the room.
Building so it can become one
The best position is often an internal tool built with product-shaped foundations.
Clean boundaries, a data model that does not assume a single organisation, and workflows that are configured rather than hardcoded. None of this requires building billing or self-serve onboarding on day one. It only requires not making decisions that foreclose them.
That approach costs somewhat more than the cheapest possible internal build, and considerably less than a full product. It buys the option to decide later, once real usage has told you whether the product exists.
Where Wall & Fifth sits
Most of this work arrives described as one thing and turns out to be the other.
The first useful conversation is usually not about the build at all. It is about separating the operational problem from the commercial opportunity, and deciding which one the money is for.
From there the route is normally New Builds for a defined first version, or Embedded Partner where the product direction needs to stay open while the software takes shape.
This decision usually matters most when
This decision usually matters most when
- You understand an industry workflow better than the software currently serving it
- You are replacing spreadsheets, disconnected systems, or manual process across a business
- You have been told your internal system could be sold, and you are unsure whether that is true
- You are scoping a first build and the budget assumes one answer without having asked the question
FAQ
Questions people usually have before the next step feels obvious.
Can an internal tool become a SaaS product later?
Yes, but only if the foundations allow it. The blocker is rarely the interface. It is a data model that assumes one organisation, hardcoded business rules, and permissions built for people you know by name. Those are structural decisions made in the first weeks of a build.
What changes in the build if I want to sell the software later?
Multi-tenancy, configurable rules rather than hardcoded ones, self-serve onboarding, billing, and a support surface. Most of these can be deferred. The one that cannot be deferred is the assumption of a single organisation, because unwinding it later is a rebuild rather than an addition.
Do I need multi-tenancy on day one?
You need a data model that does not prevent it. That is a different and much cheaper requirement than building the full multi-tenant surface before you have a second customer.
How do I know if the product is real?
Name a company other than yours that would pay for it, and check whether they could be onboarded without you present. If the answer to either is no, you are building an internal tool, which may still be exactly the right thing to build.
Related pages
Related route
If the software has to work before it has to sell, start with a defined first build.
The clearer the separation between the operational problem and the commercial one, the less the first version costs and the more it tells you.