Portals, booking systems, internal tools and apps. These projects rarely fail on code. They fail on scope: too many features at launch, no plan for who maintains it, and nobody agreeing in advance what success looks like. We spend the first weeks making the smallest useful version obvious.
Weeks
To scope the first release
Per release
Fixed price, agreed up front
Documented
Handover and admin included
In practice
The expensive mistake is not the code. It is choosing a platform for the wrong kind of use and paying for it every year afterwards.
Best for customer portals, dashboards and internal tools — anything used at a desk, or occasionally on a phone. Build cost: lowest. Deploy whenever you like, with no store review and no versioned releases.
Best for repeat use on phones — booking, job sheets, checklists — without going through an app store. Build cost: moderate. Updates instantly; offline works, though iOS notifications still have caveats.
Best for offline-heavy field work, camera or sensor use, and push notifications that are part of the product. Build cost: highest. Two codebases, two review processes, and a release cycle you do not control.
The work
Every stage below is part of the scope, in this order.
We separate what the business needs on day one from what it would like by year two. That means writing down the one job the app has to do, who does it, and what happens if it fails. Most first releases get smaller after this exercise, and better.
Customer portals, booking and scheduling tools, internal dashboards, quotation systems, marketplaces and companion apps. Authentication and roles, payments, notifications, file handling and reporting — the parts that are never in the demo and always in the invoice.
Apps are rarely standalone. We connect to accounting, CRM, email, storage, mapping and payment providers, and we plan the data migration before launch rather than during it. Where an existing system can be used instead of rebuilt, we will say so.
Monitoring, error reporting, backups and a support agreement are part of the launch, not an upsell. We hand over the code, the infrastructure and written documentation. If you later want to bring development in-house, that is a supported outcome rather than a problem.
Deliverables
Before we start
First releases get smaller once the core job is written down, and better for it.
Accounts and permissions for each type of user · the single core task, working end to end · payments, if money moves through it · an admin view so your team can run it without us · error reporting, backups and a way to roll back.
A native build for both platforms on day one · reporting dashboards nobody has asked for · single sign-on for every client at once · tiered automated billing before there is demand · a public API for partners who do not exist yet.
Selected work
Straight answers
Proposal
What has to happen, who does it now, and what breaks when it is done by hand. We will tell you the smallest useful version and what it costs.
No sales call before we understand the problem. If we are not the right studio for the job, we will say so and, where we can, point you somewhere better.
The other pillars
Sites built on modern frameworks and designed around the decisions your customers actually make. Fast, accessible, and editable by your own team.
02Technical SEO, content structure and paid search that compound over time. We start with what people search for, then build the pages that answer it.
03Identity, messaging and the design rules that hold it together. The logo is the smallest part of the job.
