New product development
Nothing built yet? That's the easiest place for us to start.
We are known for rescuing old systems, so it surprises people that a large share of our work is the opposite: a new idea, an empty repository, and a first version that has to be in someone's hands quickly. Web, desktop, iOS and Android. No legacy required.
- iOS & Android
- Web applications
- Windows desktop
- APIs & integrations
- AI-accelerated delivery
Greenfield work
The same experience that saves old systems is what makes new ones last.
Almost every legacy system we are called into was somebody's exciting new project once. We have spent nearly thirty years seeing exactly which early decisions turn into a maintenance bill and which ones quietly pay for themselves.
That is an unusual thing to bring to a first version. Most teams building something new have never had to live with the consequences of the choices they are making this week. We have, hundreds of times, in other people's code.
- Founders and first products. An idea, a market you understand well, and a need to get something real in front of users before the money or the moment runs out.
- Companies replacing a spreadsheet. The process that grew out of Excel and email and now runs a department. It deserves an actual application.
- Internal tools nobody sells. Scheduling, dispatch, quoting, inventory, compliance. Unglamorous software that decides whether a business is profitable.
- New products beside an existing system. A customer portal, a mobile companion app or a public API on top of what you already run.
- Projects that went wrong elsewhere. Brought in to work out why a new build stalled, and to get it shipping again.
How a new build runs
Working software early, then honest decisions about what comes next.
No twelve-week requirements phase that produces a document instead of a product. We want something you can click on while the idea is still fresh enough to change.
-
A conversation, not a questionnaire
What are you trying to make happen, who is it for, and how will you know it worked? We push hard on the last one. A new build without a definition of success is the most common way these projects go wrong.
-
Shape and estimate
A short paid discovery: the core workflows, the data model, the integrations, the platform choice, and a phased plan with costs. You keep the written output whatever you decide to do next, including hiring someone else.
-
A first version that actually runs
Not a clickable mockup. A working slice of the real product, on real data, deployed somewhere you can reach it. Usually weeks rather than quarters, because we are cutting scope to the spine rather than cutting quality.
-
Iterate with users in the loop
Short cycles, visible progress, and a standing invitation to change direction while changing direction is still cheap. Most first ideas are partly wrong, which is fine as long as you find out in week four.
-
Handover you could actually use
Source, documentation, deployment, and the reasoning behind the significant decisions. You should be free to take it in house or to another firm without a hostage negotiation. That has always been how we work.
We will tell you if you should not build it. Sometimes the honest answer is that an off-the-shelf product covers ninety percent of the need for a fraction of the cost. We would rather say that early than invoice you for finding it out slowly.
- Native iOS and Android. Swift and Kotlin when the app depends on platform features, performance or a genuinely native feel.
- Cross-platform where it fits. One codebase for both stores when the app is largely forms, data and workflow, which is most business software.
- Offline first. Field crews, warehouses, basements and rural routes. The app keeps working with no signal and reconciles cleanly when it comes back.
- Device capabilities. Camera and barcode scanning, GPS and geofencing, push notifications, biometrics, Bluetooth peripherals and printers.
- Talking to your existing systems. Including the ones that predate mobile phones. We build the API layer as well as the app.
- Store submission and beyond. App Store and Google Play accounts, review process, signing, phased release, crash reporting, and the OS updates that arrive every autumn whether you planned for them or not.
iOS & Android
Mobile apps, built for work rather than for a demo.
We build for iPhone, iPad and Android: apps published to the App Store and Google Play, and internal apps distributed privately to your own staff.
We will also tell you when you do not need one. A responsive web application installs nowhere, updates instantly and costs considerably less to maintain, and for a lot of requirements it is the better answer. When a phone genuinely is the right device, because of the camera, the location, the notifications or the fact that the job happens standing up, that is when an app earns its keep.
What we build
Four shapes cover most of it.
Whatever the platform, the part that matters is usually the same: a clear data model, workflows that match how the work is really done, and integrations that hold up when something upstream misbehaves.
Mobile applications
iOS and Android, public or internal. Offline-capable, connected to your back end, and maintained past launch day.
Web applications
Database-backed products, customer portals and marketplaces. Fast, accessible, and built to be maintained by someone other than us.
Desktop software
Windows line-of-business applications for work that is genuinely better on a full keyboard, two monitors and a local device.
APIs & platforms
The services underneath everything above, including integrations with the systems your customers and suppliers already use.
AI-accelerated delivery
A new build is where the AI advantage shows up fastest.
On a fresh codebase there is no thirty-year-old constraint to work around, so the tooling gets to run at full speed. Scaffolding, test suites, API clients, data seeding and migrations: work that used to fill the first month now fills part of the first week.
The rule does not change. We do not ship code no engineer has read.
- More options explored, sooner. Two or three real prototypes in the time one used to take, which is how you find out that the obvious design was the wrong one.
- Tests from day one. The safety net gets built alongside the feature instead of being promised for later and never written.
- AI features in the product itself. Document extraction, semantic search, classification and in-app assistants, scoped to each user's permissions and built with sensible fallbacks.
- Smaller team, same output. Senior engineers with good tooling, rather than a large team and the coordination cost that comes with it.
Common questions
What people ask before starting something new.
I have an idea but no technical background. Is that a problem?
No. It is the situation we deal with most often, and it is why we start with a conversation rather than a specification. You are the expert on the problem and the customer. We are the experts on what it costs to build, what will be painful later, and which parts you should not build at all in version one.
How long until we have something we can show people?
For a focused first version, typically weeks rather than months. That depends far more on how ruthless we are about scope than on how fast anyone types. Part of discovery is agreeing what the smallest genuinely useful version is, and then protecting it.
Do we need both an iOS app and an Android app?
Usually yes if it is consumer-facing, and often not if it is for your own staff on devices you control. Where both are needed, a shared codebase is frequently the right call. We make that choice per project rather than defaulting to whatever we built last, and we explain the trade-off before you commit to it.
Who owns the code?
You do. Source, repository, documentation and deployment, handed over as we go rather than at the end. We want to keep clients because they want to keep us, not because leaving is difficult.
Can you take over after launch, or do we need our own team?
Either. Some clients keep us on for ongoing development and support, some hire in and use us to help onboard them, and some take it away entirely. All three are fine, and we build with the third in mind regardless, since that is the only way to be sure the handover is real.
How do you price a new build?
Discovery is fixed price and fixed duration, so you know the cost of finding out. After that we quote phase by phase: fixed price where the scope is genuinely clear, time and materials where it is not. We would rather tell you which of those you are looking at than present a precise-looking number we would have to renegotiate.
Tell us what you want to exist.
Even a rough description is enough to start. We will tell you what it would take to build, what we would leave out of the first version, and whether we are the right firm for it.