Fixed points
True on every project.
Scope changes from job to job. These do not, and you can hold us to them from the first conversation.
- You own the code. The source is yours, in your repository, from the first week.
- You own the accounts. Hosting, domain, app stores and API keys go in your company name, not ours.
- We tell you when not to build. If the arithmetic does not clear the build cost, we would rather say so than take the project.
- We will say if an off-the-shelf tool would do it cheaper. Sometimes the right answer costs us the job.
- Nothing gets built without a written scope and a price you agreed to first.
- Plain language throughout, progress updates and invoices included.
The work
Five steps, in this order.
Nothing here is unusual. What matters is that each step ends with something you can read, use or say no to.
- 01
We look at how the work happens now
The first conversations
A couple of calls, and where you can show us, a look at the real spreadsheets, the paperwork and the screens your team stares at all day. The process you already have usually contains the requirements.
- Who does the work, and what it costs them in hours
- The spreadsheets and systems already in play
- Every place the same thing gets typed in twice
- What has to keep running while we build
- 02
Scope, timeline and price, in writing
Before any code
Before any code. What we are building, what we are deliberately not building, when it lands and what it costs. If a tool you can buy for a monthly fee would do the job, we tell you that instead.
- A written scope you can hold us to
- A price for the first phase, in writing
- What is explicitly out of scope
- An honest "do not build this" where that is the answer
- 03
Something you can click, early
Most of the project
You get a working version to use, not screenshots to approve. Then we shape it with you as it goes, instead of revealing it at the end and finding out we misunderstood something in week two.
- A usable version in the first weeks
- Short check-ins in plain language
- Changes made while they are still cheap
- The people who scoped it are the people building it
- 04
Launch, with your data and your team ready
Cutover
We move your history across and check it against the original, train the people who will actually use it, and go live at the quietest hour with a way back if something looks wrong.
- Old data imported, then reconciled against the source
- Training for the people who use it daily
- Written guides in your own words
- The old system readable until you are certain
- 05
We stay on for the part that matters
Ongoing
The real edge cases turn up once real people use it with real data. We stay on through the weeks after launch to fix them. After that you either keep us for changes or take it in-house, and both are fine.
- Fixes for what only real use finds
- Monitoring and alerts when something breaks
- Source code, accounts and documentation are yours
- Keep us on, or hand it to your own developer
Your side
What we need from you.
Projects rarely fail on the technical part. They fail when nobody on the client side has the time or the authority to answer questions, and the build drifts away from the real work.
- One person who can decide
- Projects stall when every question has to go round a committee. We need one person on your side who can answer a question and make a call without arranging a meeting first.
- A few hours from the people who do the work
- Time with whoever is on the front desk, in the workshop or on the phones is worth more than a week with a manager. They know where the process really breaks, because they are the ones working around it.
- Access to what already exists
- The spreadsheets, the logins, the export from the old system, the person who set it up years ago. The sooner we see the real thing rather than a description of it, the fewer surprises land later.
- Honest answers about the awkward parts
- The workaround nobody admits to, the customer who gets special treatment, the report the board actually reads. Those are requirements, and they only show up if someone says them out loud.
- A decision when we ask for one
- We bring you choices with a recommendation, not a blank form. Waiting three weeks for an answer moves the launch date by three weeks, and we would rather flag that early than absorb it quietly.
Questions people ask before starting
How long does it take?
It depends, and the honest drivers are these: how many people and systems the work touches, how messy the existing data is, whether it has to work on phones or offline, and how quickly decisions come back from your side. A single automation is a short project. A system a whole team runs on is a long one. You get a date in writing before any code, and if it slips you hear about it the week it slips, not the week before launch.
How much does it cost?
We do not publish prices, because the same sentence from two businesses can mean a two-week job or a six-month one. What moves the number: how many systems it has to talk to, how much old data has to come across, how many different kinds of user there are, and whether it needs phones, offline working or payments. You get a price for the first phase in writing before we start, and if the numbers do not work we say so.
What if we already have a developer?
That is common and it is fine. We can take one piece and hand it over, work alongside them on the parts they do not cover, or review what exists and tell you what we would do. We use standard tools and write documentation, so your developer can read what we built. Sometimes the honest answer is that your own developer should do this and we say that too.
What happens after launch?
Software is not finished at launch. The real edge cases arrive in the first weeks, with real people and real data, so we stay on through that. After that most clients keep us on a small monthly arrangement for changes and fixes, and some take it in-house. You own the code and the accounts either way, so both stay possible.
What if we do not know what we need yet?
That is the normal starting point, and it is what step one is for. You describe what keeps going wrong and who it affects; working out what should be built is our job, not a prerequisite for talking to us. Plenty of these conversations end with a short answer and no project, which is a fine outcome.
Next step
Tell us what is not working.
Describe the problem in your own words. We reply with an honest read on whether it is worth building, roughly what it takes, and what we would do first.