Free AI and software strategy consultation

Technology strategy is a phrase that has been worn smooth by overuse, but underneath it is something concrete: the set of decisions that determine what your software will cost to change in two years. Almost everything else is implementation detail. A team can recover from choosing an unfashionable framework. It cannot easily recover from a data model that encoded the wrong assumption about how the business works, or from service boundaries drawn along the org chart rather than along the things that actually change together.

This is why software architecture consulting is worth more at the beginning of a project than at any later point, and why it is so rarely bought then. At the start there is nothing to show for it: no screens, no demo, nothing that looks like progress to a board. The value is entirely in the mistakes that now will not happen, and those are invisible by definition. Six months later the same advice costs a rewrite.

The practical consequence is that the most useful hour you can spend on a software project usually happens before anyone has written a line of code, and it is spent arguing about what the system has to be true about rather than which tools will build it.

Nothing has widened the gap between a demonstration and a production system quite like generative AI. It is now trivial to build something that looks extraordinary in a fifteen-minute meeting and impossible to rely on. The reason is not that the models are bad. They are remarkable and improving faster than any of us can keep up with. The reason is that a demo is judged by whether it impressed the room, and a system is judged by what it does on its worst input, at its busiest hour, when nobody is watching.

AI strategy work, done properly, spends most of its time on questions that have nothing to do with models. Can you actually reach the data the system would need, or does it live in a database somebody else owns and nobody wants to touch? How would you know the output was wrong? What is the cost of a wrong answer, and who carries it? Is there a rule or a query that would do this more cheaply and more predictably? What does this cost per month at real volume, and does that still make sense at ten times the traffic?

Those questions decide whether an AI project succeeds. The model choice, which is what most conversations start with, is close to the least consequential decision in the entire programme and gets easier every quarter regardless of what you pick.

Greenfield projects get written about because they are easy to write about. Most real enterprise software work happens somewhere less photogenic: a system that has been running for eight years, that nobody fully understands, that three departments depend on, and that cannot be switched off for a weekend.

Legacy modernisation is mostly an exercise in archaeology followed by an exercise in restraint. The archaeology is working out what the system actually does, as opposed to what its documentation claims and what the remaining team believes. The restraint is resisting the rewrite. A full rewrite is the most commonly proposed and most commonly regretted answer in enterprise software, because it replaces a system with known flaws by a system with unknown ones, and it takes far longer than anyone estimated because the original encoded a decade of edge cases nobody wrote down.

The more reliable path is usually to find the seams, put a boundary around the part that hurts most, replace that, and repeat. It is less satisfying and it works considerably more often. Working out where those seams are is exactly the kind of thing an hour with an outsider is good for, because the people closest to a system are often the least able to see it in pieces.

Cloud migration projects fail in the cutover and in the data, almost never in the destination platform. The new environment is rarely the hard part. The hard part is that the old system has undocumented dependencies, that some of the data is subtly wrong in ways the application has been quietly compensating for, and that the business cannot stop trading while you find out.

The second thing worth saying about cloud is that the bill is an architecture problem wearing a finance costume. A cloud bill that grows faster than your traffic is telling you something structural: about how data moves between services, about what is running when nothing is happening, about a query pattern that made sense at small scale. Cutting it by negotiating a discount treats the symptom. Cutting it by changing where the data lives treats the cause, and tends to make the system faster as a side effect.

This is worth raising in a consultation because cost, performance and architecture are the same conversation, and they are usually held separately by three different people who each report a problem nobody can solve alone.

Digital transformation has become a budget line rather than a description of anything. Where it does mean something, it means changing how work happens rather than putting a web interface on how work already happens. That distinction decides whether the programme returns anything.

The failure pattern is consistent: an eighteen-month programme with a single large release at the end, a scope agreed before anybody learned anything, and a delivery date that survives contact with reality for about a quarter. The alternative is not agile as a ceremony. It is sequencing the work so that each phase puts something genuinely usable in front of real users, which forces the assumptions to be tested while there is still budget and appetite to act on what you learn.

Enterprise automation belongs in the same conversation. The highest-return automation is nearly always an unglamorous internal process that a few people do by hand every day, and it is nearly always overlooked in favour of something more visible. Finding it is a matter of asking which task everyone complains about, then asking how long it takes and how often it happens.

Early-stage companies have an unusual problem: nearly every technical decision is cheap to make and expensive to unmake, and there is no one in the room whose job it is to say so. The founder is validating a market. The first engineers are shipping. Nobody is asking which of these choices will still be defensible when there are twenty people and a compliance requirement.

Product discovery in that context is not a research phase to be completed. It is the discipline of deciding what to build first so that the first release proves or disproves something specific. A first version that merely exists tells you nothing. A first version that tests the riskiest assumption tells you whether to continue.

The most valuable thing an experienced engineer can usually offer an early team is subtraction: identifying the two thirds of the planned scope that can wait, and the small number of decisions that genuinely need to be right now because they will be load-bearing later. Custom software consulting at this stage is worth far more as a filter than as an accelerator.

A consultation is only as good as what you bring to it. The single most useful thing is a clear statement of what must not break, because that constrains the answer more than any preference does. After that: the constraint you cannot change, whether it is a regulator, a deadline, a platform decision already made or a team of three; what you have already tried, so the hour is not spent suggesting it; and someone who knows how the current system behaves in production rather than how it was designed.

Be honest about budget shape if there is one. Not so the answer can be priced to it, but because the right recommendation at fifty thousand is a genuinely different recommendation from the right one at five, and an adviser who does not know which one you are in is guessing.

Finally, treat scepticism as a good sign. An adviser who agrees with your plan immediately is either right or not listening, and the odds are not in your favour. The hour is worth most when it changes your mind about something, and that is only possible if the person you are speaking to is willing to say the uncomfortable thing.