A running app
We launch the app and you get documentation for it.
No lengthy analysis, no hundred-page specification. Show us how you do things today and see how it could work.
Process
We go through how things work for you today and where they get stuck. We tell you whether an app makes sense or whether a better spreadsheet will do.
Before you decide, you see how the app would look and work. You get an estimate of scope and price in our proposal, not on the website.
We build the app in parts and go through each one together. If something needs to change along the way, we tell you in advance what it means for scope and price.
We launch the app and hand it over. What exactly you get and how we look after it afterwards is agreed in the contract up front.
We launch the app and you get documentation for it.
Sign-in, backups and tests of the critical logic. These never get skipped, even in a hurry.
Chosen per project. No closed in-house system that only our people understand.
Who owns the code, where the data lives and how the app is handed over is agreed before we start. We never reuse a client’s data or business rules in other projects.
This is a summary. The binding terms are in the contract.
When a simple rule or a database query does the job, we don’t use AI. Where it saves work, we do. Numbers are always calculated by the database, not the model, and people make the decisions that matter. We always tell you what the model will see and where the data goes.
We stick to what we do well. For these projects we’ll tell you straight away that we’re not the right fit.
Projects for dozens of teams with multi-year plans and formal change management need a different delivery model than ours.
Medical devices, licensed financial products and critical systems that must run around the clock.
Before we take over an existing app, we review it. Only then do we commit to scope and price.
These are specialised fields with their own platforms.