How I work
How we’d work together, from the first call to the day you don’t need me.
You bring the workflow and the people who live it. I bring a way of working that keeps the outcome, the evidence and the decisions visible at every step, so you are never guessing where the project stands or what it will cost to stop.
The plan, in three steps.
Tell me the problem
Thirty minutes. Bring the last time it went wrong, or the role you need filled.
We scope a paid trial
The outcome, the price and who signs off, written down first. Easy to stop.
Working software every week
Real slices on your real workflow. You decide what comes next.
What to bring
- The last time the process went wrong, in as much detail as you can stand. A real case beats the ideal version.
- Who touches the work: the people who do it, the person who decides, the person who has to accept the result.
- What a good result would mean in plain words. “Fewer late deliveries” is enough to start.
You get a written playback within a few days: what I understood, what is evidence and what is assumption, and a recommended next step. Sometimes that recommendation is not to build anything yet.
What the trial agreement covers
- The problem in one paragraph, in your words.
- The deliverable: one end-to-end outcome, not a pile of components.
- Who accepts it, in which real scenario, using what evidence.
- What you provide: a process owner, a recent case, data or access in an approved way.
- The stop rule: what result would make us stop or change course.
A trial is priced as a fixed scope or a capped number of hours. Discovery beyond a short capped conversation is paid work, so neither side is guessing about commitment.
The weekly loop
- Promise: one beneficiary, one outcome, the evidence that will show it, the date.
- Back-brief: before building, I explain the problem and approach back to you in my own words, so misunderstandings surface early.
- Build: changes small enough to inspect and reverse. AI-generated code is treated as untrusted until reviewed.
- Verify: the primary workflow, the likely failure cases, permissions, and what happens when an integration is down.
- Demo on your real workflow, with what was checked and what was not, then your decision on the next slice.
Every update follows the same shape: the outcome attempted, the evidence produced, any promise at risk, the decision needed and by when, and the next move.
What you can expect from me
Straight answers, small changes, dated next steps.
- A recommendation before a list of questions. If I can inspect it myself, I do not ask you to.
- Every open item has an owner and a dated next event. “Waiting” is not a status.
- What was checked and what was not, in writing, before you see a demo.
- Security, privacy and the exit plan are designed in discovery, not in launch week.
- Acceptance, adoption and value are treated as three different things, and measured separately.
- Bad news early and plainly. Politeness never hides a risk.
What I’ll need from you
- A process owner who knows the real work and can answer “what happens next” without checking.
- One recent concrete case to walk through, including the parts that went sideways.
- A decision maker who can accept a result, and roughly 30 minutes a week of their attention.
- Data or access through a route you approve. I will not work around a control to move faster.
Compared with the alternatives
What you would get anywhere else.
- An agencyhandoffs and “spec first.”One owner and a demo every week.
- A freelancerwork that needs directing.Finds the problem, then fixes it.
- A full-time senior hirefour months to find, then onboarding.A paid trial week, then you decide.
- A fractional CTOadvice.Builds it.
If you are hiring an engineer
A senior product engineer you can test before you decide.
Some teams do not have a project to hand over. They have a gap: a senior engineer who can own a problem end to end, sit with the operators, design the screen, ship the code and stand behind it. That is the seat I fill, as a contractor or full-time, remote on US hours. Forward-deployed engineer, product engineer, founding engineer: the title matters less than the shape of the work.
The hiring test is a paid trial week on your real problem. You see commits in your codebase, a working slice in front of a real user, and the written update I send every week. If it is not a fit, you have paid for a week and learned something about the problem.
What the first week looks like
- Day one: read the code, the tickets and the last incident. Ask for the recent case that went wrong.
- Day two: a written back-brief of the problem, the approach and the non-goals, before I change anything.
- Days three to four: the smallest end-to-end slice, with tests, behind a flag if needed.
- Day five: demo to the person who lives with the problem, plus the update: what worked, what did not, what is next.
When it’s not a fit
Better to say so on day one.
- You need a large team on site next week. I work remotely, hands-on, and bring people in deliberately.
- You want a fixed specification built to the letter with no contact until delivery. The weekly loop is the product.
- The work needs regulated data that cannot be shared under a defined control. Better to say so on day one.
Principles I won’t trade
- Discovery studies the problem before committing to a solution. It may conclude that software is not the answer.
- Outcomes and acceptance are defined before material delivery starts.
- Deliver in small, observable slices. Volume is not progress.
- Reusable learning crosses the boundary; your data and confidential material never do.
Questions people ask first
The practical details.
Where are you based, and which hours do you work?
I work remotely from Indonesia and overlap US working hours. Most clients see me in their morning and their afternoon. Written updates land on a fixed day each week.
What kinds of problems fit best?
An operational workflow that has outgrown spreadsheets and manual review, a product or feature that needs to ship, or an AI capability that has to stay inside your rules and survive a real reviewer. Logistics, field operations, compliance workflows, decision support and internal tools have all worked well.
What does a scoped paid trial look like in practice?
Two to four weeks, one end-to-end outcome, a named person who accepts it, and a stop rule. It is priced up front as a fixed scope or capped hours. At the end you decide whether to continue, change direction, or stop, and you keep everything built.
Do you take full-time roles, or only contracts?
Both. Contracts and scoped paid trials are the usual start, and a full-time role is a good outcome when the fit is clear. Remote from Indonesia with US-hours overlap either way. My résumé is one page and lives in the site header.
What is a forward-deployed engineer, and is that you?
An engineer who works inside the customer’s workflow rather than behind a product backlog: discovery with the operators, a build shaped by their day, deployment, and adoption. That is how I have worked since Quantum’s first client, so yes, with the caveat that I also design the interface and own the product decisions when asked.
Do you work alone or with a team?
I do the product, design and engineering work myself first. When a slice needs more hands, I bring in people I have worked with through Quantum, and I stay accountable for the outcome. You always know who is doing what.
Which technologies do you use?
Mostly TypeScript and React on the front end, Python and Django or Node on the back end, and PostgreSQL. AI features use hosted models with constrained outputs, confidence and reasoning shown to reviewers. The stack follows your constraints, not my preferences.
How do you use AI in the work itself?
Daily, for drafting, tests and exploration, and never as a substitute for review. AI-generated code is treated as untrusted until it is read, run and checked against the acceptance scenario.
How does an engagement end?
With a handover you can operate: documentation, access transferred, support boundaries written down, and a clean close on data and credentials. Renewal is a separate decision, made on adoption and value evidence rather than momentum.
Bring me the problem. I’ll bring the plan.
Thirty minutes. Bring the last time it went wrong. You leave with a straight answer.