The problem
The template did the job until the business grew around it, and now every change is a workaround on top of a workaround. Nobody on the team can say whether the fix is one more plugin or a build of your own, and nobody will say how long a build should take.
What goes wrong
- The custom build is scoped as a rewrite of everything. It runs for quarters, and the business changes before anything ships.
- It is built for launch day, not the week after. No rollback, no deploy log, and nobody on your side who can change a headline without a developer.
- Unconfirmed facts go live. A placeholder date or a guessed claim ships because nobody marked it, and a customer finds it first.
The approach
- Decide custom against one test: the thing you need the software to do that the platform cannot, written in one sentence. No sentence, no custom build yet.
- Ship the smallest custom piece first, on your domain, in accounts you own.
- Mark every fact nobody has confirmed. The production build fails until each mark is cleared, so nothing unconfirmed goes live.
- Hand it over with a documented rollback, a deploy log, and a handoff session, so your team owns it from day one.
When it works
When the people who will use it are in the room, someone on your side will own it after launch, and the first version is small. When the wish list covers every page and every integration, it is a rewrite.
When off-the-shelf stops fitting
Templates and platforms are the right call for longer than most founders want to admit. A store on a good theme, a site on a page builder, a form tool wired to a spreadsheet: that stack carries a brand to its first real customers. The problem shows up later. The business grows a shape the platform did not plan for, and every change becomes a workaround. A plugin to patch the plugin. A manual step between two tools that should talk. A checkout that cannot do the one thing your best customers ask for.
The test for going custom is one sentence. Write down the thing you need the software to do that the platform cannot. If you can write it, build it. If you cannot, you do not need a custom build yet. You need a better setup of what you have.
What a custom build should cost in time
Time is the honest unit. A build that takes quarters before anyone uses it is scoped wrong, whatever the reason. The business will change before it ships, and the people who asked for it will have moved on.
A web app with its own accounts, data, and workflows is scoped in the 10-day assessment first, with your team in the room, ending in a written plan.
Mobile adds a second codebase to maintain and an app store review you do not control. For most consumer brands the right order is the web version first, measured, then the app when the numbers say customers want you on their home screen.
How we build it
We start with the one sentence and the smallest build that satisfies it. On your domain, in accounts you own, so your team can cut off our access in one step.
Every fact in the copy that nobody has confirmed is marked in the build, and the production build fails while any mark remains. Nothing unconfirmed goes live by accident. Every page has a readable fallback: when a visitor has motion turned off or scripts fail, they still get the page.
Launch comes with a documented rollback, a deploy log, and a handoff session. Your team gets the runbook. If you want us to keep running it, content and SEO are a monthly option.
What it looks like when it works
TICKR Energy: Webaroo co-founded it. Vluxure: Webaroo built the member platform and runs the technology behind the club.
Where to start
If the site or store is the thing to fix, start with Storefront. If the system you have outgrown runs the whole business, read legacy modernization first. If you make or distribute what you sell, manufacturing and distribution covers the orders and invoices behind the store. If you are not sure the custom build is the first thing, ask Roo, Webaroo's AI: Do we need a custom build, or a better setup of what we have?
Book 15 minutes with Connor