Skip to main content
Ways To Work Together

What I take on, and what that looks like

Some teams need someone to write the code. Others need someone to lead the people writing it. Here's roughly where I fit, and what you'll actually have in your hands once we're done.

Full-Stack Product Delivery

You need a real, working product, and there's nobody around who can take the whole thing on, from the data model right down to the box it runs on. That's the gap I fill.

I build the whole thing: the frontend, the backend, the database, and the servers it all runs on. One person owns it end to end, so nothing falls through the cracks between two teams.

What the work covers

  • We agree on the architecture and data model
  • A frontend built to your designs, or designed together if you don't have any yet
  • Backend APIs, login, and roles and access management
  • The database: schema, migrations, and enough seed data to actually test it
  • Cloud setup, CI/CD, and deployment to production
  • Payments, email, and whatever third parties you need wired in

What you walk away with

  • The code in your repo, under your account
  • Docs for the architecture and the deployments
  • Live staging and production environments in accounts that belong to you
  • A proper walkthrough afterwards

Typical timeline. Usually somewhere between six and sixteen weeks. It comes down to how much of it is genuinely new versus things I have built plenty of times before.

Where I've done this:Comet Courier platform and admin

Fractional CTO & Technical Lead

You've got developers but nobody senior enough to make the hard calls. Or the team has quietly ground to a halt and nobody can quite tell you why. Either way, I've been the person brought in to sort that out.

I run the engineering side so you can get back to running the company. I make the calls that keep your developers moving, and I turn whatever the board is asking for into work the team can actually ship.

What the work covers

  • Technical direction and the architecture decisions required
  • A roadmap, sprint planning, and a delivery rhythm
  • Code review and engineering standards, either for a fresh team or one you already have
  • Hiring: I write the specs and run the technical interviews
  • The calls on infrastructure, third party integrations, and what they would cost, if necessary

What you walk away with

  • Properly documented architecture decisions
  • A dedicated team that keeps working even when I'm not fully around or available
  • A clear ownership for every system, so nothing gets orphaned when someone leaves or moves on

Typical timeline. Ongoing, usually two or three days a week, with a three-month minimum to start. Honestly, nothing real about how a team works changes any faster than that.

Where I've done this:Chepaticket Ticketing Platform

Business Website

You need something credible online, and you need it soon. And you'd rather not have to call a developer every single time you want to change a sentence?

I will build a site you're actually proud to include on your business card or portfolio. It's fast, it works properly on a phone, and it can take payments and bookings. Usually live in under two weeks, and you can edit it yourself after that.

What the work covers

  • Design and build, phone first, and tested on actual phones
  • A CMS so you or your team can change the words and pictures without me
  • Payments and bookings through whichever gateway you already use or prefer
  • Analytics and SEO basics depending on your requirements
  • Domain, hosting, and business email, all set up properly

What you walk away with

  • Admin access to everything, in your name and your accounts
  • A short screen recording showing you how to update it yourself, if you want one

Typical timeline. Two to four weeks, and most of that is usually me waiting on your copy and other related media.

Where I've done this:Romulus Construct
How I Work

The same five steps, every time

None of this is unnecessary, and that's the point. It's written down because the projects that go bad are nearly always the ones where nobody bothered to sort these things out at the start.

01

A call, first

Give me thirty minutes. Tell me what you're building, what's gone wrong, and what you've already tried. If I'm not the right fit, you'll hear that on the call as well.

02

Scope in writing

I write back what I heard: what I'll build, what I'm deliberately leaving out, and how long it'll take. Nothing kicks off until we both look at that and agree it's right.

03

Weekly, visible increments

Every week there will always be something on a staging link you can click through yourself. This helps to prevent the project from going sideways.

04

Proper handover

I write technical documentation, record a live walkthrough, and ensure that you have access to all the technical resources afterwards. If the project needs a developer on speed dial to keep running, then it means we actually haven't finished the job.

05

Maintenance

For a month after launch, anything that breaks is on me, not you. The first few weeks in production are where the sneaky bugs show up, so that's exactly when you want me still paying attention.

Where I'm Not The Fit

The work I turn down

I'd rather be straight about this now. It saves us both a lot of time, mine included.

Fixed price on an unfixed scope

I'm happy to fix the price. I just need the scope pinned down as well, or one of us ends up frustrated down the line, and it's usually both of us.

Just extra hands on a fixed backlog

If you've already got a lead and a locked-down spec and you only need another pair of hands to clear the backlog, a full-time hire or a more junior contractor will stretch your budget further than I will. It's a value thing, not a willingness one, and I'll happily point you toward the cheaper option.

A rescue with no access

I'll happily take over something somebody else walked away from. But I need the repo, the servers, and any other technical requirement or resources. If one or all of these are not available, then we can discuss a fresh project instead.

Live next week

Honest timelines start at about two weeks for a website and six for a web application. I'd rather lose the work than promise you a date I already know isn't real.

Before You Ask

The stuff people ask me on the first call

Do you work with existing teams and codebases?

Almost always, yeah. Most of what I've done is exactly this: either leading a team that was already there, or picking up a system someone else started.

Who owns the code?

You do, completely. It sits in your repo, under your account and I set the infrastructure up in your accounts wherever I can.

How does payment work?

Projects get split into milestones, with a deposit to get started. Retainers are billed monthly, up front. Either way, it's all written down before I begin, so nothing gets renegotiated on you halfway through.

What happens when the scope changes?

It usually does, and that's fine. Changes get priced and agreed upon before I build them; that's the whole reason the scope goes in writing up front.

Do you handle maintenance afterwards?

The first thirty days of fixes are on me. After that, I'll either quote you a monthly retainer or help your own team take it over, whichever one actually works out cheaper for you.

Are you available for full-time roles?

Yes. Alongside client work, I'm open to senior engineering and tech lead roles, especially at product-led companies and Series A to C startups where the big technical decisions are still up for grabs.

Not sure which of these you actually need? Tell me what the problem is and I'll point you the right way, even if that turns out to be someone other than me.

Let's talk

Let's build something
that actually works.

Take 30 minutes on my calendar. Tell me what you're building, what's broken, or what your team is missing and watch me bring your project to life, piece by piece.

Book a free call