Co-founder · Engineering Leadership

I run engineering.I still review the code.

Three years ago I started a development studio with a partner. It's four to eight people depending on the month, and it ships somewhere between sixteen and thirty client projects a year. About half of those clients come back. I do the estimating, the hiring and the code review, and I built all of this alongside a full-time engineering job.

4–8

Team size

Employees and contractors, varying by month

16–30

Projects a year

Client work shipped across the studio

~50%

Clients who return

Roughly half commission again

2–3 yrs

Longest client

Almost the studio's whole life

All of this was built alongside full-time engineering roles — LogoPidea, then Tech Cabin. I'm not hiding that, and I'd rather answer it up front than have it found on LinkedIn.

Two decisions

What I'd beasked about

One process, one technical. Both are things an interviewer can dig into, which is more than a list of capabilities offers.

Process

A scope breach, and the document that came out of it

Situation: A client's expectations drifted past what we'd agreed. On a $6–7k engagement there isn't margin to absorb that quietly, and there wasn't a written record of where the line had been.
What I did: I took it to the client directly and walked them through the actual effort our team had spent against what was scoped. They agreed. The relationship survived and the project finished.
What changed: Every scope document since has a section listing what is explicitly not included. Naming the exclusions up front stops the conversation happening at invoice time, when it always goes badly. It costs an hour to write and it has never cost us a client since.

Architecture

Putting the booking rules in Postgres instead of the app

Situation: Dinely is a restaurant reservation platform. Two people hitting the same table at the same second is the one failure the product cannot have.
What I did: The scheduling and availability rules live in the database — roughly 38k lines of PL/pgSQL — rather than in application code. A double booking is rejected by Postgres, not caught by a check in the request handler.
What I rejected: Enforcing it in the app layer, which is faster to write and what most of these systems do. It also can't guarantee correctness once two requests are in flight at once.
What changed: It held. The trade is that the logic is harder to change and harder for a new developer to pick up, which is a real cost and one I'd make again for this particular guarantee.

What I run

Three,honestly

Xtenzium

Custom development studio

Co-founderRunning

Client engineering. Engagements are typically $6–7k, which means the margin lives or dies on how accurately the work was scoped. Most of what I know about running a team came from getting that wrong and then fixing it.

Elevon

Running · product

SaaS with a marketplace side

Our own product rather than client work. Different failure mode: nobody is paying an invoice at the end of the month, so priorities have to be argued rather than assigned.

Overlap

In build

Engineering studio, US working hours

A studio built around a shifted schedule so a Pakistan-based team overlaps the US business day. Currently being launched.

Visit

How the studio runs

Four rules

Not a process diagram. These are the four things actually enforced, and each exists because something went wrong without it.

Scope says what we're not doing

Every proposal lists exclusions, not just inclusions. This came out of the breach above and it's the single most useful thing I've added.

Estimates come from the architecture

I cost against how the thing will actually be built. At $6–7k an engagement, an estimate that's 30% out isn't a rounding error, it's the profit.

I review the work

Not all of it, but enough that I know what's going out. A lead who has stopped reading the code is managing a report, not a team.

Handover means they own it

Documentation and access transfer at the end. A client who can't leave isn't a retained client, they're a hostage — and about half of ours come back anyway.

Terms

What wouldmake me move

I'm not trying to walk away from what I've built. A Head of Development role would have to be worth leaving it for, which for me means three things.

01
Engineering is still hands-on
Small enough that whoever leads it is expected to build. I'd be bad at a job where I only read dashboards.
02
The team is mine to shape
Hiring, standards and how the work gets reviewed. Not inheriting a process I'm not allowed to change.
03
The product is the business
Engineering treated as where the company is made rather than a cost line to be managed down.

Head of Development · Remote — US-hours overlap, or any timezone

See the engineering

Email: airafadil619@gmail.com
Phone: +92 334 3365685
LinkedIn: Muhammad Airaf Adil
Based: Karachi, Pakistan