Everything We Build
Ten services, but they are not really ten separate businesses. Almost every project uses four or five of them at once, which is the reason they sit under one roof: nobody has to translate between the person who designed it, the person who built it, and the person who has to keep it online.
You Do Not Have To Pick Correctly
Choosing a service from a list assumes you already know what the work is, and at the start you usually do not. So here is the same list read the other way round: find the sentence that sounds like your situation, and start there. If you land on the wrong one, we will say so on the call.
- You have an idea and nothing else yetStart with the Idea to Execution Blueprint. You get the requirements, architecture and plan in writing, and you can take it to anyone to build.
- You know exactly what you want builtGo straight to web, mobile or desktop, whichever your users will actually be sitting in front of.
- There is hardware involvedIoT Solutions covers the device, the firmware and the platform that has to keep receiving from it once there are a thousand of them.
- It exists but nobody wants to use itUI/UX Design, usually starting with watching real people fail to complete the thing they came to do.
- The bill or the downtime is the problemCloud Services. Most surprising cloud bills are two or three misconfigured things, not a pricing problem.
- Things keep breaking in productionQA & Testing, to find out whether the cause is missing tests, missing process, or a design that was always going to do this.
- You are about to sign something expensiveConsulting. We will read the quote, the scope and the contract, and give you the questions to put back to the vendor.
- You need advisory rather than deliveryOur consultancy practice covers strategy, transformation and governance as longer-running engagements.
- You are hiring juniors who need to be usefulIndustrial Training puts engineering graduates on a real project with real code review.
The first call costs nothing.
Use it to find out what you need, not to be sold something.
How An Engagement Actually Runs
Same shape whichever service you came in through. The point of writing it down is that you can hold us to it, and that you know what the next two weeks look like before you commit to anything.
-
01
Free call
What you are actually trying to do
Not a demo and not a pitch. What the problem is, who it is for, what the budget looks like, and whether the thing you described and the money you have can be made to meet.
-
02
Before starting
Scope and price in writing
What is included, what is deliberately not, how long it takes and what it costs. Agreed before any work begins, so the surprises happen now rather than in month three.
-
03
Week one
Set up in your accounts
Repository, cloud and third-party services created in your name from the start. You are never in a position where leaving us means losing something.
-
04
Throughout
Build in the open
Working software you can click on at short intervals, not a status percentage. When something slips you hear it in that week, with what we are doing about it.
-
05
Before launch
Test it like a stranger will
Real devices, bad networks, wrong inputs and the load you expect on your worst day. Launch day should be boring, and it usually is when this part was not skipped.
-
06
After
Stay reachable
Support and changes if you want them, a documented handover and a proper walkthrough if your own team is taking over. Either way the same people are still on the other end.
A Small Team That Also Runs Its Own Software
Building something and then living with it are different skills, and only the second one teaches you what actually breaks. We run our own products in production, which means we are the ones who get woken up when they fall over. It shows in what we build for other people.
Hands-on experience per engineer, across agencies, product companies and enterprises. Nobody here is learning on your project.
Small on purpose. You talk to the people writing the code, not to an account manager relaying it back to them.
We build, ship and maintain our own software, so we know what a real deployment does at 2am. More on how we work.
Everything is in your name
Repositories, cloud accounts, domains and third-party services belong to you from the first day. There is no handover to negotiate and nothing that stops working if you move on.
Your information stays yours
We will sign a mutual Non-Disclosure Agreement any time you want one, at no cost. You can read the exact document we use before you ask for it.
Looking for advisory rather than delivery?
Our consultancy practice covers strategy, architecture, cloud, security and digital transformation, for teams that need direction before they need developers.
Frequently Asked Questions
Which service do I actually need?
Often the honest answer is that you are not ready to pick one yet, and that is what the Idea to Execution Blueprint is for. If you already know what you are building, pick the service that matches the platform and we will tell you on the first call which of the others the work will genuinely need. Most projects touch three or four of them, and you are not expected to work that out yourself before calling.
Can you handle the whole thing, or only part of it?
Both. We can take an idea from a blank page through design, build, testing, launch and the years after it, or we can slot into a team that already exists and take one piece. The second is more common than people expect. If you have engineers already, the useful thing is usually the part they do not have time for or have not done before, not a replacement for them.
How much does a project cost?
It depends entirely on scope, and any number given before we understand the scope is a guess dressed up as a quote. What we can promise is the sequence: a free first call, then a written scope with a fixed price for that scope, agreed before anything starts. If the budget you have and the thing you described do not fit together, we will say so on the first call rather than three months in.
How long does it take?
A Blueprint is a few weeks. A small focused build is usually one to three months. Anything larger is broken into releases so you have something real in front of users early rather than a single delivery date at the end. Timelines are agreed in writing with the scope, and when something slips you hear it from us in that week, not in the final report.
Who owns the code and the accounts?
You do, from the first commit. The repository, the cloud accounts, the domains and the third-party services are all in your name, and we work inside them. There is no handover event to negotiate at the end and nothing that stops working if you decide to continue with somebody else. We will also sign a mutual NDA before the first call at no cost.
What happens after launch?
Launch is the point at which real usage starts teaching you things, so it is the least useful place to disappear. We stay on for support and changes where you want that, and where you would rather your own team took over we document the system and walk them through it properly. We also run our own products, so we are the people who get paged when something breaks at night, and we build accordingly.
- Free first call, with an engineer, no obligation
- Scope and price agreed in writing before any work starts
- Mutual NDA on request, before the first call
- Code, accounts and infrastructure in your name from day one