Platform architecture consulting

Which database. What a user is. Whether identity is yours or a provider's. Whether a tenant is a column or a schema.

None of those looks like a decision at the time. Each one looks like getting started.

They are made in the first week and they are expensive to reverse in every week after it.

A year later they are load-bearing, nobody wrote down why, and the person who would have known has moved on.

That is the problem. It shows up as a team that has stopped being able to say yes to things, and as a roadmap where every item quietly costs more than the last.

Most people who ask for this can describe the symptom precisely and cannot name the cause. Estimates that keep growing. A change in one place that breaks something in another.

A new hire who takes months to become useful, because the reasoning lives in a conversation nobody recorded.

The constraint on this service is that the advice has to be usable by people who are not me.

A recommendation only I can carry out is not advice; it is a dependency with a document attached.

So the output is written down in language a team can argue with, and the reasoning comes with it so a future reader can decide it was wrong. That is the point of it.

The second constraint is the catalogue's rather than this service's. A recommendation does not get to assume a paid service in the critical path, or a server somebody has to keep alive, unless that cost is named, priced and agreed first.

The third is about honesty rather than technology. A review can always return a longer list of problems than the system actually has. So the record names what should stay as clearly as what should change, and that section gets written first.

What an engagement of this shape produces is a document rather than a deployment.

Stack selection with the trade-offs written down, including the ones arguing against the choice I recommend. A data model and access-pattern review, which is mostly reading the queries rather than the schema, because the queries are what the schema is for.

Cost modelling against real usage, built from your own numbers so you can run it again after they move. A migration path from what exists today, whose intermediate states each have to work on their own. And a written record a future team can argue with.

The findings live in the queries. A schema is a guess about the future; the queries are what actually happened, and reading them in order explains a cost line better than any diagram.

The cost model is the deliverable people expect least and use most. It is a spreadsheet you keep, not a slide I present, and its inputs are the read counts, row counts and request volumes your product already produces.

Migration paths get the same treatment. Each step is written so the work can stop after it, which is the difference between a plan and an ambition.

My name is Ahsan Mahmood, and the reason the record is written to be argued with is that I will not be in the room when it matters.

The costs are honest, and there are four.

One is that the written record takes time that ships no feature, and it is the deliverable most likely to be cut when a week gets tight. Cutting it removes the only part that outlives me.

Another is that the recommendation is often to change less than you expected. A rewrite is a recommendation I have to earn, not a default, and a review ending in keep this, fix these four things and move on is a review that has just reduced its own scope.

A migration path is also slower than a rewrite. Every intermediate state has to work in production while people are using it, which is exactly why the path finishes and the rewrite sometimes does not.

The fourth is yours rather than mine. Advice nobody acts on is worse than no advice, because it becomes a document people cite to explain why nothing changed.

What this service does not do is take the decision for you. I can put the trade-offs in writing, model the cost and name the path, and the choice stays with whoever has to live with it.

Implementation afterwards is a separate engagement, quoted separately. Turning it down changes nothing about the record you already hold.

The rest of the exclusions are the catalogue's. Visual design as a standalone deliverable. Native iOS. Blockchain work. Copywriting and content.

One more belongs here.

I will not tell you your architecture is fine when it is not, and I will not tell you it is broken because a rewrite would be more interesting to build.