Loading
Eleven services, four clusters
Most projects touch three or four of these before they are finished. Take one piece, or describe the outcome and let us map the work backwards from it.
These are not eleven separate businesses sharing a logo. They are the stages of the same job, and a service page is simply the place where one stage is described in detail.
A typical engagement looks like this. Design decides what the thing is. Engineering builds it. Cloud and DevOps decide how it gets deployed and what happens at 2am. Security tests what was built before a customer does. Data makes the result measurable, and automation removes the manual steps the new system exposed. Growth is what happens when the product is worth sending traffic to.
You do not have to buy all of it, and we will say when a stage is not worth paying for yet. The most common honest answer to an enquiry about one of these services is that a different one should come first.
What each area covers
Nine areas of work, grouped the way projects actually run rather than the way an org chart would arrange them.
Agents that carry out a multi-step task under a permission list, retrieval systems that answer from your own documents, and document pipelines that read what currently arrives as a PDF attachment. Paired with reporting, because an automation you cannot measure is one you cannot defend.
Systems for the process that no package models correctly: operations tools, approval workflows, integration layers and the internal applications that sit between two bought products. Built in typed code, with the handover documentation written while the work happens.
Marketing sites and web applications are two different builds. We do both and decide which one you are asking for before quoting either, with a performance budget enforced in the pipeline rather than measured after launch.
One Flutter codebase for both stores where the app is screens and data, native Swift or Kotlin where it depends on platform depth, and an honest conversation about whether the workflow justifies an install at all.
Tenancy, billing, onboarding and the admin console, which is the part that separates a product from a demo. Scoped so a first release is narrow in features and complete in the loop from signup to payment to usage data.
Environments rebuildable from a repository, a deployment path any engineer can run, and testing that finds the authorisation flaws a scanner cannot see. These two are sold separately and are usually bought together for good reason.
Agreed metric definitions, pipelines in version control, and dashboards that get opened at shift start rather than at the steering meeting. The definitions come first, because a chart on top of a disagreement just distributes it faster.
Research, flows and interface design specified down to the loading, empty and permission-denied states, with tokens shared between the design library and the code so the two do not drift apart during the build.
Moving an operation off paper and spreadsheets in phases that each stand on their own, and then making the result findable: technical SEO, local search and paid media measured against enquiries instead of impressions.
All eleven
Put AI to work on the tasks that eat your team's week.
Software, web and mobile, engineered to last.
The infrastructure and safeguards underneath it all.
Make it clear, usable and findable.
Commercials
The model is chosen from how settled the scope is, not from what is easiest to invoice. Whichever one applies, the repository, the cloud accounts and the domain stay in your name.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
How to read this
Match the situation, not the service name. Each row names where we would start and what usually follows it — the linked service is the next step, not the whole answer. If two rows describe you, both routes end at the same conversation.
06 starting points · every route links to a real service page
Send a paragraph describing what is not working. You will get a written reply from someone who would be on the build, saying which of these we would start with, what a first phase looks like, and where our estimate is least certain.
