Fractional Tech Lead
AI tools have made your team faster at writing code. They haven't made anyone better at deciding what code should exist. Architecture gets decided by whoever prompted last, and without someone senior to say "not like that," a quick fix becomes the thing everyone has to work around for the next two years.
I join your team part-time as a fractional tech lead. I make architecture decisions on purpose instead of by accident, write down the conventions your developers and their AI tools should follow, and set up the automated checks that catch the mistakes I'd otherwise point out in review. I still read code, but I focus on the changes that can actually hurt you: data migrations, authentication, billing, and anything that changes how the system fits together. It's a monthly retainer, so you get a senior engineer's judgment without hiring a full-time staff engineer you can't justify yet.
Who needs a fractional tech lead?
A fractional tech lead is a good fit if:
- Your team ships more code than ever, and pull requests get approved because CI is green, and your CI doesn't check for the things that matter
- Your most experienced developer spends more time untangling generated code than building anything
- Founders, product managers, or junior developers are shipping AI-written features and you're not sure what's underneath
- You've inherited a codebase that was mostly generated and need someone to tell you what's worth keeping
- You're between senior hires and can't afford to lose technical direction in the meantime
How the retainer works
Kickoff call
We go over your codebase, team, and priorities, and agree on the scope: which parts of the system I own decisions for, which meetings I attend, and how quickly I respond.
Review and baseline
In the first couple of weeks, I read through the codebase, review work in progress, and write up what I'd change and why. That gives us a shared starting point and tells you early whether my calls line up with how you want to work.
Ongoing leadership
Every month, I join planning and architecture discussions, keep the team's conventions and AI tool instructions up to date, and turn the mistakes I keep seeing into CI checks and automated review rules. I review the changes that carry real risk, check in on what's been merged, and answer questions asynchronously.
What you'll get
- Reviews of the changes that carry real risk, from someone with 15+ years of hands-on Rails experience, focused on what will hurt you six months from now
- Architecture and backend decisions with the reasoning written down, so the team understands the why and not just the what
- Someone who knows which shortcuts are fine and which ones you'll pay for later
- A team that gets better at spotting problems in generated code on its own
- Standards and guardrails that stay in place after the engagement ends
Pricing
Retainer with a defined scope and a 3-month minimum. We agree on review coverage, meeting cadence, and response times up front, and the price stays fixed so you can budget for it.
Frequently Asked Questions
How much of your time do we get?
It's defined by scope rather than hours. We settle the details during the kickoff call and write them into the proposal. If the scope needs to change, we adjust the retainer, so neither of us spends time tracking hours.
Will you review every pull request?
No, and with AI tools in the mix, nobody should. A part-time reviewer on every merge just becomes a bottleneck. Instead, we agree on which changes need a senior set of eyes, like data migrations, authentication, billing, and new dependencies, and I review those. The rest is covered by the standards and automated checks we put in place, and I look back over what's been merged to catch anything they missed.
Why a 3-month minimum?
Changing how a team reviews code and makes decisions takes longer than a sprint. The first month is mostly learning your codebase and setting a baseline. The real value shows up in the months after that.
Do you write code too?
Sometimes, when it's the fastest way to show the team the right pattern or unblock something critical. But if you mainly need more hands to ship features, another developer or an AI tool is the cheaper option. What you're paying for here is the decisions and the standards, not more output.
Do you use AI tools yourself?
Every day, which is how I know where they go wrong. They'll happily write code that looks finished but misses an edge case, or tests that pass without checking anything useful. I won't try to talk you out of using them. I'd rather help your team get output from them that's worth keeping.
How do you integrate with our team?
I join your Slack or whatever your team uses, sit in on the planning and architecture discussions that matter, and work within your existing Git workflow. The goal is to be part of how the team makes decisions, not an outside reviewer who shows up once a week.
What if we eventually want to hire someone full-time?
I'm not looking for full-time work, but I can help with the transition. That includes documenting the decisions I've made and why, helping you define the role, and evaluating candidates.
Does this cover frontend work?
My strengths are on the backend, infrastructure, and testing side. I'll catch the obvious problems in frontend code, but if most of your risk lives in the frontend, I'm probably not the right fit.
Ready to add a senior voice to your team?
Book a free consultation so we can talk through how your team ships today and whether a fractional tech lead is the right fit.
Request a Free Consultation