Services · 06
Technology strategyDecide what to build, and in what order, before anyone builds it
A written read of what you run today, what it is costing you, and what to do in what order. You keep all of it, whoever builds.
Decide first. Build second.
Owners are asked to make technology decisions on the worst possible evidence: three proposals that do not compare, a vendor’s diagram, and a nephew who says the whole thing should be rebuilt. The cost of getting it wrong is not the fee, it is the two years spent on the wrong system and the people who stopped trusting the tools.
This work is the deciding, done properly and separately from the building. We read what you run today, what it costs you in money and in people’s time, and what it can and cannot carry. You get a findings document, a plan in the order things should happen, and the questions to put to any vendor, including us. It is vendor-neutral by design: we say when the answer is a product you can simply buy, when it is to fix what you have, and when it is to do nothing this year.
- Team
- The named owners, for the whole engagement
- Runs in
- Your own accounts, from day one
- Pricing
- Fixed price, billed by milestone; a fixed itemised quote follows the first call
- Three vendors, three proposals, and no way to compare them
- A system that works but cannot carry the next five years
- A board or a lender asking what the technology plan is
- A findings document naming what to fix, in order of what it costs you
- A costed plan you can take to any builder, not only to us
- The questions to ask a vendor, and the answers that should worry you
- A second opinion in writing, including when the answer is to do nothing
Four gates. You accept each one before the next starts.
The same four as every engagement, as they look for this work.
Diagnose
We interview the people who use the systems and the people who pay for them, list what you run, and put a cost against each thing that is going wrong. The findings document ranks them by what they cost you, not by what is interesting to build.
Prove
The riskiest assumption in the plan gets tested rather than argued about: a small prototype, a trial of a product you could buy, or a measurement of the thing everyone believes is slow. What comes back changes the plan, in writing, before any money follows it.
Build
The plan is written in the order things should happen, each step with what it costs to build and to run, what it depends on, and what it retires. Where a vendor is the right answer, you get the questions to ask them and the answers that should worry you.
Hand over
You keep everything: the findings, the plan, the prototype, the vendor questions. We present it to whoever needs to hear it, including a board or a lender, and we say plainly where we would and would not be the right people to build it.
Quote to dispatch on one workflow, confirmed from the floor.
A furniture maker with two workshops and dealers in nine cities. Orders moved on paper, and nobody knew where one stood without walking the floor.
Job cards and dealer updates retyped by hand
documents typed a second time from a record that already held the same facts
- Quote to dispatchdays from an accepted quote to the piece leaving the workshop, averaged over the month
- Office time spent chasing order statustime at the desk answering where an order has reached, counted against the month before the build
What owners ask before they call.
We have three proposals that do not compare. Can you read them?
Yes, and it is one of the most useful days we spend with an owner. Proposals are usually incomparable because each vendor has quietly assumed a different scope, a different amount of your team’s time, and a different answer to what happens after go-live. We put them on one page in the same terms, name what each one leaves out, work out what each would cost to keep running, and write down the questions to put back to all three. You keep that whether or not you ever work with us.
Is our current system worth saving?
More often than vendors will tell you, because the vendor who says rebuild is the vendor who gets paid to rebuild. The questions that decide it are plain: can anyone safely change it, does it lose data, can it be connected to the other things you run, and is anyone still supporting what it is built on. If three of those four are fine, the answer is nearly always to keep it and fix the fourth. When it genuinely cannot be carried forward we say so, and what the move involves is written down with costs before you decide.
What does a technology review actually produce?
Documents you can act on without us: a map of what you run and how it fits together, a list of what is going wrong with a cost against each, a risk register naming the single points of failure and the places you are locked in, and a plan in the order things should happen with costs to build and to run. Plus the vendor questions. It is deliberately written for the owner and the board rather than for engineers, with the technical annexe kept separate for whoever advises you.
Will you tell us not to build something?
Regularly, and it is the main reason to bring in someone who is not selling you the build. The commonest honest answers are that the process needs changing before any software can help, that a product you can buy off the shelf does nearly all of it, or that the problem will disappear anyway when something else is fixed first. We would rather say that and be trusted with the work that is real than sell you a system you did not need.
Can you help us choose a vendor and then not be the vendor?
Yes, and we will say up front where we would be a poor choice for the build. If the work needs fifty engineers, a licence only a big firm holds, or a product specialism we do not have, you need a different builder, and the plan is written so any competent one can pick it up. Where we would be the right people we say that too, and you are free to take the plan elsewhere; it is yours either way, which is what keeps the advice honest.
How is this different from the two-week discovery sprint?
The sprint is aimed at one problem you have already decided to solve: it ends in a findings document, a prototype and a costed build plan for that piece of work. A strategy engagement is wider and starts a step earlier, across everything you run, when the question is what to do at all and in what order. Owners often do the strategy work first and then the sprint on whatever came out top, but either can stand alone, and both are fixed price with both founders in the room.
For your technical adviser
Architecture review, build-versus-buy analysis, vendor and contract review, and a migration path with costs. Vendor-neutral: we say when the answer is a product you can buy, and when it is nothing at all.
- Current-state architecture and integration map
- Build-versus-buy analysis with total cost of ownership
- Risk register: single points of failure, lock-in, key-person risk
- Sequenced migration plan with costs and decommission dates
Stack Vendor-neutral · reviews any stack you already run
The pyramid is the problem, not the people
Why the people who write the plan are the ones who would have to live with it.
Write a paragraph. A founder replies within one working day.
A 30-minute call with both founders follows. No deck and no proposal template, just a first read of whether we are the right shape for the problem.
Or by phone or WhatsApp: +91 94330 54299 · WhatsApp (opens in new tab)