How I work
I take on a small number of engagements at a time so each client gets real attention. The goal of every engagement is the same: solve the actual problem, ship something maintainable, and leave your team able to extend it without me.
What to expect
1. First contact
You email me with the problem — not a spec, just what you’re trying to accomplish and why now. For a short-term project (a code review, a quick sanity check, a focused session) there’s no sales cycle: I confirm scope by email and we go. Everything is remote — Zoom and email, never on-site.
2. A free 30-minute conversation
For larger work — a full project, ongoing advisory, a technical review — we start with a free 30-minute call. I’m not pitching on this call. I’m trying to understand the problem, what you’ve already tried, who’s on the team, and what success looks like in three months. If it’s not a fit, I’ll tell you, and I’ll usually point you somewhere better.
3. A one-page proposal
If it’s a fit, you get a proposal within a week: the problem in your words, concrete deliverables (not a pile of hours), a timeline with milestones, a single investment number, and an explicit list of what’s out of scope. That last part prevents most of the friction later.
4. Kickoff
On a yes, the contract goes out within a day. Project work is milestone-based; retainers are billed in advance. Then a kickoff that confirms start date, access, and a weekly check-in cadence so nothing drifts.
5. Delivery — and handoff
I don’t sub-contract the building. The person you talked to is the person writing the code. Every engagement is structured so your team can maintain and extend what I deliver — documentation, walkthroughs, and working sessions are part of the deliverable, not an afterthought.
What I bring
- Hands-on experience. I’ve built and maintained production systems, not just slide decks.
- One point of contact. The person you talk to is the one building it.
- A broad background. IT, AI/ML, mobile, web, and DevOps — useful when a problem crosses a few of those.
- Handoff in mind. The goal is that your team can maintain and extend the work without me.
- A practical view of AI. I use it a lot and try to be upfront about where it helps and where it doesn’t.
Good fit / not a fit
I’m probably a good fit if you want an engineer who can both plan and build, who treats AI as a tool rather than a magic wand, and who’s happy to teach your team along the way. Small, focused short-term projects are some of the most useful work I do — I’m happy to take those on as readily as longer ones. Everything is remote.
I’m not the right fit for full product MVPs in a week, pure staff augmentation with no architectural input, or projects already locked into an unrealistic deadline. If you’re not sure, ask — I’d rather tell you “no, and here’s why” than take on work I can’t deliver well.
When you’re ready, the rates and engagement shapes are here, or just email me and we’ll figure out the right shape together.