sssystemsAvailable

Sole proprietor engineer · consulting, roadmaps, systems

I map systemsbefore I rebuildthem.

I get called in when a system has outgrown the plan it was built on. I find out what is really running, write the plan that replaces it, and then do the work — one engineer, in your repo, on your standups.

Start a conversation
Practice
Independent since 2019
Based
Remote · UTC+8
Booking
Reviews from 2 weeks out
A

How the work goes

Three phases, in order. Most clients start at the first one and decide about the rest afterwards.

01Consult

Find out what's actually there

Every system I get called into is already running, already load-bearing, and already different from its documentation. I start by reading it — the code, the schema, the incident history, and the people who know where the bodies are.

  • Trace the real request paths, not the ones on the wiki
  • Sit with the engineers who carry the pager
  • Separate the failures that hurt from the ones that annoy

You getA written review: what you have, what will break next, what it costs to leave alone.

02Roadmap

Write the plan that replaces it

A roadmap is only useful if you can staff it. I sequence work by risk and dependency, size it against the team you actually have, and mark the decisions that have to be made before anything gets built.

  • Phased, with a first milestone you can ship in weeks
  • Explicit about tradeoffs, cost, and what stays broken
  • Sized for your team, not a hypothetical one

You getA sequenced plan with milestones, dependencies, and open decisions. Yours whether or not I build it.

03Build

Then build it

I do the work, not just the deck. Small reviewable increments, tests that mean something, and documentation written as I go — so the thing I hand back keeps running after I leave.

  • Increments that ship, behind flags where it matters
  • Migrations run with a rollback that has been rehearsed
  • Handover docs and a walkthrough with your team

You getWorking systems in production, and a team that can maintain them without me.

intakeauthapiqueueworkerdbcachereportbilling
01Found9 services · 12 dependencies · 1 fault
B

Engagements

Four shapes of work. They combine — a review that turns into a roadmap that turns into a build is the usual path.

SS-01

System review

Duration
2–3 weeks
Commitment
Part-time

A fixed-scope read of one system. Ends in a written review and a working session with your team.

  • Architecture and data-flow map
  • Ranked risk register
  • Cost-of-inaction estimate
  • Two hours of walkthrough

Right whenYou inherited something, or something keeps breaking and nobody can say why.

SS-02

Technical roadmap

Duration
3–4 weeks
Commitment
Part-time

Turns a review — mine or yours — into a plan with dates, owners, and an order that survives contact with reality.

  • Phased delivery plan
  • Dependency and risk sequencing
  • Staffing and effort sizing
  • Decision log with open questions

Right whenYou know roughly what needs to happen and need it ordered, sized, and defensible to a board.

SS-03

Build engagement

Duration
2–6 months
Commitment
2–5 days/week

Hands on keyboard, inside your repo and your standups, shipping the plan in increments.

  • Backend, data, and integration work
  • Migrations and cutovers
  • CI, observability, and runbooks
  • Documented handover

Right whenThe plan exists and you need capacity that does not require six weeks of onboarding.

SS-04

Standing advisor

Duration
Ongoing
Commitment
2–4 days/month

A senior engineer on call for design reviews, hiring loops, vendor decisions, and the question you don't want to ask in public.

  • Architecture and design review
  • Interview and hiring support
  • Build-vs-buy calls
  • Async access between sessions

Right whenYou have a team but no one senior enough to argue with.

C

What I hold to

  • A roadmap you cannot staff is a wish list with dates on it.
  • The system you already have is the requirements document. Read it before you write a new one.
  • Estimates get better when the plan gets smaller, not when the spreadsheet gets bigger.
  • Most rewrites are a planning problem wearing a code costume.
  • If the handover needs me in the room, the work is not finished.
D

What I work in

Deep in the first three rows, fluent in the rest. I pick up new stacks for the length of an engagement and say so when the learning curve is yours to pay for.

Languages
  • TypeScript
  • Python
  • Go
  • SQL
  • Bash
Backend
  • Node
  • FastAPI
  • Postgres
  • Redis
  • Kafka
  • gRPC
Data
  • dbt
  • Airflow
  • Snowflake
  • DuckDB
  • Event modelling
Infra
  • AWS
  • Terraform
  • Docker
  • Kubernetes
  • GitHub Actions
Frontend
  • React
  • Next.js
  • Internal tools
  • Design systems
Practice
  • Incident review
  • Observability
  • Migration planning
  • Technical due diligence
E

Working details

The answers that otherwise cost an email round-trip.

Availability
Taking new engagements. Reviews can usually start within two weeks; build work is booked further out.
How I work
Remote, with travel for kickoffs and workshops where it earns its keep. I overlap at least four hours with your team's day.
Billing
Fixed price for reviews and roadmaps, so the scope is the contract. Day rate for build work and advisory, invoiced monthly.
Contracts
Your paper or mine. I sign NDAs without negotiation and carry professional indemnity cover.
Working with your team
I join your standups, your repo, and your review queue. I am a contractor, not a black box.
What I don't do
Staff augmentation by the headcount, fixed-bid builds off a spec I did not help write, or plans I am not willing to execute myself.

Tell me what you are trying to build, or what keeps breaking.

A paragraph is enough to start. If I am not the right person I will say so in the reply, and usually name someone who is.

stevensisjayawan34400@gmail.com