Most of what a founder asks us to build already exists. The scoping work is finding the quarter that does not.
The most useful hour of any kickoff is the one where we take things off the build list. Founders arrive with a feature list and assume our job is to agree with it. Our job is usually the opposite: to find the quarter of that list that is actually theirs, and to buy or skip the rest.
Most software is plumbing. Authentication, payments, invoicing, notifications, file storage, video calls, analytics. Every product needs them and no product wins because of them. They are solved, they are boring, and building them yourself is a decision to maintain someone else’s solved problem forever.
Tinrate is a good example, because on paper it sounds like heavy financial engineering. Payments are held until the call happens. Experts get VAT-compliant invoices. That reads like a custom payment system, and it is not one. It is a payment provider doing what payment providers do, plus our rules on top of it and a tax configuration that took a fraction of the effort of writing a ledger. We wrote the logic that decides when money moves. We did not write the part that moves it.
That distinction matters more than it sounds. A payment bug in a provider’s system is their engineer’s weekend. A payment bug in a system you built is your product roadmap for the next month, and it happens at the worst possible moment, which is when money is already flowing.
WERKR is where the custom budget went somewhere no vendor could have covered it. Matching hundreds of flexible workers to niche jobs, automotive cleaning, Airbnb cleaning, event staff, with real scheduling constraints, is not a category you can buy. That planning and dispatch logic is the reason the platform runs 500+ active workers without the back office growing at the same rate. Nothing off the shelf models that, so we built it, properly, and bought everything around it.
Jobr is the same shape. The custom part is the matching that puts fitting vacancies in front of a candidate daily. The chat, the push notifications, the store pipelines: all standard, all bought or boilerplate. If we had spread the budget evenly across the feature list, the matching would have been the thing that got rushed, because it is the hardest.
The test we use is blunt. If a competitor could buy the same capability tomorrow, it is not your product, it is a line item. Spend accordingly.
Occasionally a founder describes an idea that is entirely plumbing. A form, a payment, a confirmation email, a spreadsheet someone checks. Version one of that is a weekend with existing tools, not a development project, and we say so. We lose work that way. We would rather lose a project than take money to build something the client could have rented for forty euros a month, because that client talks to other founders.
Custom earns its cost in three situations we keep seeing: your workflow has constraints no vendor models, your matching or data compounds into something competitors cannot copy, or you have wired together so many tools that the integration mess now costs more than one owned system would.
The pitch for buying usually skips the bill. Every tool is a subscription, a dependency, and a vendor whose roadmap is not yours. The rule we apply: buy where the vendor’s incentive is permanently aligned with keeping it working, like payments and authentication, because their whole business dies if it breaks. Build where the vendor’s roadmap will drift away from what your product needs, because that drift is the thing that hurts you in year two.
So the scoping question is not whether we can build something. We can build most of it. The question is whether anyone would notice if we did not.
We build websites, software and companies. Tell us which one you need.