An independent software consultant who ships
A software consultant is an outside engineer you bring in to solve a specific technical problem – a slow system, a decision you can’t make with confidence, a project that won’t finish. I’m an independent one: you get me, not a team of juniors managed by an account director.
I’ve spent 20+ years in production across 200+ projects, and I still write code. Engagements start with a two-week sprint so you can judge the work before committing to more.
Independent consultant, agency or freelancer?
The term software consulting covers very different services. Choosing the wrong kind is an expensive mistake, so here’s the honest comparison:
- A software development agency sells capacity. You get a team, a project manager and a statement of work. It’s the right choice when the problem is well defined and you need many hands to build it. It’s the wrong choice when nobody yet knows what the right solution is.
- A freelance developer sells hours against tickets you write. Good value for defined tasks; risky if you need someone to tell you the tickets are wrong.
- An independent senior consultant sells judgement plus execution. One experienced person who diagnoses the problem, makes the call, and does or leads the work. Fewer hours, more done per hour, and it doesn’t scale to building a whole product from scratch alone.
- A big consultancy sells process, assurance and headcount. Useful when you need a brand name on a report for a board or regulator.
I’m the third option. If you’re weighing the first two against each other, the guide on staff augmentation vs outsourcing covers that decision.
Problems I’m brought in for
- Architecture decisions with a long tail – splitting a monolith (often you shouldn’t), multi-tenancy, moving off a platform, choosing between two frameworks. See software architecture consulting.
- Performance and reliability – the database that slows down every month, the queue that backs up, the deploy that takes an hour.
- Delivery that has stalled – the team is busy but nothing reaches production.
- Payments and money movement – integrations, reconciliation, webhooks, ledgers. I wrote a book on this, the Payments Playbook.
- Legacy code – old PHP, old Rails, unsupported framework versions, code nobody wants to touch.
- Adding AI features to an existing product without blowing the budget or the error rate.
- A second opinion before a big spend: a rebuild proposal, a vendor quote, an architecture an agency has pitched you.
How an engagement works
- A short call. You describe the problem. I tell you whether I’m the right person, and if I’m not, who or what might be.
- A two-week sprint. I get access to the code and the people. By the end, something real has shipped and you have a short written view: what’s wrong, what I’d do, what it would take.
- Then one of three things. You take the plan and run it yourself; I stay on for a fixed number of days a week to lead the work; or we stop. All three are fine outcomes.
There’s no notice period and no exit clause. I work remotely from GMT+2, overlapping European hours and US East Coast mornings, and I’m async-first: written decisions, recorded walkthroughs, and fewer meetings.
What a good software engineering consultant leaves behind
The test of a consultant isn’t the report – it’s what your team can do after they leave. I aim to leave three things: working code in your repository, decisions written down with the reasoning so they can be revisited sensibly, and at least one person on your team who now owns the area I worked on.
If you finish an engagement and still need me to explain your own system, I haven’t done the job.
Who I’m not the right technical consultant for
- Teams looking for low-cost development capacity. An agency or a nearshore team will be better value.
- Projects that need someone on-site five days a week.
- Pure staff augmentation where you want an extra pair of hands and no opinions.
- Work that needs a large team immediately, like building a whole platform from zero in three months.
If any of those describe you, I’d rather say so on the first call than two weeks in.
Background
I co-founded and sold a software studio that delivered 200+ projects across fintech, gaming, e-commerce and big data. I was CTO through an acquisition, an early engineer at Yola as it grew from 10K to 11M users, and the architect behind loyalty and student platforms with millions of users between them. I still build my own products, including Craaft and the Nitro static site generator that runs this site.
Questions
What does a software consultant do?
A software consultant diagnoses and solves specific technical problems for a company: architecture decisions, performance issues, stalled projects, integrations or code quality. Good ones also do or lead the implementation, rather than handing over recommendations for someone else to carry out.
Is a software development consultant cheaper than an agency?
Per hour, usually not. Per problem solved, often yes, because a senior consultant spends fewer hours finding the real issue. For large, well-defined build work an agency is usually the better deal, since you’re buying capacity rather than diagnosis.
Do you write code or only advise?
I write code. Every engagement includes shipping something real into production, usually in the first two weeks. Advice that isn’t grounded in your actual codebase tends to be generic, and I’d rather show you than tell you.
How do I choose a software consultant?
Ask what they’ll deliver in the first two weeks, who exactly does the work, and what they’ve built that you can look at. Be wary of anyone who proposes a long discovery phase before touching code, or who recommends a rewrite before reading it.
Got a technical problem you can’t get unstuck?
Describe it in a few lines. If I’m the right person we’ll scope a two-week sprint; if not, I’ll point you somewhere better.
GMT+2 · Full EU overlap · US East mornings