An established small business and a six-month-old startup have almost nothing in common except size. One is trying to stop losing hours to manual work; the other is trying to find out whether anyone will pay. Building the same thing for both is how budgets get wasted.
It worked at five people. At twenty it is the thing everyone complains about, nobody can change safely, and one person understands. That is the moment custom software starts paying for itself.
An order arrives in one system and gets re-entered into another. Nobody budgeted for that role, and it grows with revenue.
The expensive mistake is a polished product for a problem nobody confirmed. The cheap version of the idea, in front of ten real users, answers more than another month of building.
Distribution kills more early products than code quality ever has. If there is no path to the first fifty users, the build is not the constraint.
The one nobody can change safely and one person understands. Rebuilt as something with permissions, history and validation, keeping the workflow your team already knows.
Orders, invoicing, CRM and fulfillment talking to each other so the same information stops being typed twice. This is usually the fastest payback available to an established small business.
For an early startup: the smallest thing that lets a real customer pay, built to be thrown away if the answer comes back no. Cheap enough that being wrong is survivable.
Common, well-supported tools so your first engineering hire is a normal search and not a specialist hunt. Fashionable frameworks are a hiring problem you inherit later.
For an established business the goal is connecting what you already pay for. For a startup it is picking boring, common technology so your first engineering hire is not a specialist hunt.
When your process is genuinely different from what the templates assume and you are paying for that difference in daily friction, or when per-user pricing at your headcount has outgrown what a build would cost. If your needs match what an existing tool already does well, buy it. We would rather say that than take the project.
Usually the smallest thing that lets you charge someone, not the product you imagine. If you can deliver the service manually to your first ten customers and learn from it, that is worth more than a polished build, and it costs a fraction.
If one person can hold the whole operation in their head and nothing is falling through, you probably do not need custom software yet. The signal is usually the opposite: work that gets dropped, numbers that disagree, and a spreadsheet nobody wants to touch.
With an established business we start from the process that hurts and the systems already in place. With a startup we start from who pays and what they need to see to pay, and cut scope hard. The first is optimization, the second is discovery, and they are run differently.
Tell us which part is costing you the most right now. If the answer is something you can fix without hiring us, we'll say that on the call.
Tell us what you need and we'll get back to you. No commitment, no sales pitch.
Salomon Web Services