Platform architecture consulting — services — Ahsan Mahmood
Reviewing and reshaping an existing codebase so the next year of work is cheaper than the last.
The decisions that are expensive to reverse — stack, data model, boundaries — made before the code that depends on them exists.
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.
from $800
How long it takes
Small features 1–2 weeks, an MVP 4–8 weeks, a full production app 8–16 weeks. Those are ranges I have hit on work of that shape before. The scoping call settles how many decisions the review has to make, because an architecture engagement is sized by that list and not by the number of screens.
Every engagement of this shape covers
- Stack selection with the trade-offs written down
- Data model and access-pattern review
- Cost modelling against real usage
- Migration path from what exists today
- A written record a future team can argue with
Built with
- Postgres
- Firestore
- Architecture
Can you review or take over a codebase somebody else wrote?
Yes, and it starts with an audit rather than a feature. You get a written read on code quality, security and performance, and a prioritised list — which includes the parts I would leave alone. A rewrite is a recommendation I have to earn, not a default.
What do I actually receive at the end?
A written record: the stack decision with its trade-offs, a data-model and access-pattern review, a cost model built from your own usage numbers, and a migration path from what exists today. It is written for a team to argue with rather than for me to present. Nothing in it needs me to be the person who carries it out.
How is the cost model built?
From your own numbers rather than from a benchmark, which is what makes it something you can run again after those numbers change. Read counts, row counts and request volumes are the inputs, set against the pricing of whichever options are being compared. That is also why it stays useful once the engagement ends.
What if the answer is to change nothing?
Then that is the answer, written down with the reasoning attached. A rewrite is a recommendation I have to earn, not a default. A review ending in keep this and fix four things has just reduced its own scope, and that is the right outcome more often than it is a disappointing one.
What does an architecture review cost?
The number comes from scope, integrations and timeline — and you get it in writing after the scoping call, never before it. I do not quote from a brief alone, because the quotes that come from briefs alone are the ones that get revised upward later. How much of the system is in scope is the first thing that call settles, since a review of one boundary is a different piece of work from a review of a whole platform.
https://aoneahsan.com/services/platform-architecture-consulting