MUHAMMAD
NAVEED AKRAM

• Set and hold technical direction — what gets built, in what order, and what is deliberately not being built yet.
• Own the calls that are expensive to reverse: technology selection, build-versus-buy, the data model, where the service boundaries go.
• Sit between the founders and the engineers and translate in both directions, so neither is guessing at the other.
• Stay close enough to the code to be accountable for the advice — I review the pull requests and write the difficult parts myself.

WHAT IT ISN'T Not a stand-in for a full-time CTO once you have thirty engineers and a board. At that point the job becomes helping you hire one and handing over cleanly.

• Remote by default and long practised at it — years of shipping into Singapore, Tokyo, Dubai and Europe from wherever the work needed me to be.
• On-site is genuinely on the table, relocation included, for an organisation whose engineering I already respect.
• The role that works is one where the architecture is mine to own and I am still writing code — principal, staff, architect, or the first senior hire who has to be all three at once.
• Selective about this one, and openly so. I am not between things, so a move has to be a step rather than a sideways shuffle.

WHAT IT ISN'T Not a generic senior full-stack seat. If the job is throughput against someone else's architecture, you would be paying for judgment you have no intention of using, and I would be restless inside a quarter.

• I read the code and the infrastructure rather than the deck, then write up what will hold, what will not, and the order in which it gives way.
• Every finding carries what fixing it costs — in weeks, in money, and in what you have to stop doing meanwhile.
• You keep the document. It is written so that a non-technical founder and the engineer who has to do the work can both act on the same page.

WHAT IT ISN'T Not a rubber stamp for a decision already taken. If the architecture is sound I will say so and the engagement ends early.

• Technology selection through shipped MVP, with the architecture chosen for the next two years rather than for the demo.
• I have done this solo, end to end — a construction takeoff and cost-estimation product, technology selection to launch in twelve months at fifteen to twenty hours a week.
• Where a team already exists I take the load-bearing parts and leave the rest to them, which is usually faster than taking all of it.

WHAT IT ISN'T Not an agency. I am one person, so throughput has a ceiling — what you are buying is judgment density, not capacity.

• Led the design and launch of AI-enabled products that generate per-learner training pathways, moving a platform off static content and onto adaptive ones.
• The interesting work is rarely the model. It is grounding, evaluation, cost per request, what happens when the provider is down, and being able to say why the system answered the way it did.
• The agent on this site is a small worked example — grounded so it cannot drift from the source, rate-limited, and capped by a hard daily token budget.
• Strong algorithmic and data-science instincts underneath, so this is not prompt-wrapping dressed up as engineering.

WHAT IT ISN'T Not model training or original research. I build products around models rather than building the models, and I would rather say that now than have you find it out expensively.

• Write the bar for the role before the first CV lands, so the decision is made against a standard rather than against the last candidate you saw.
• Run the technical interviews and hand back a reasoned recommendation, not a score out of five.
• Done repeatedly — recruiting engineering teams from scratch, and vetting senior hires for founders who cannot yet assess senior engineers themselves.

WHAT IT ISN'T Not sourcing. There is no candidate pipeline here — the job is making sure the people you find are the right ones.