Consulting for Technical People

From engineer to consultant: client management, scoping, and delivery.

The hardest part of leaving a salaried job is not the technical work. The code is the easy part. What's hard is learning to operate as a business—finding clients, scoping engagements, pricing your time, and managing expectations when you're the only one on the hook.

I left full-time employment two years ago to work as an independent AI consultant. Since then, I've built adverse media screening systems, RAG pipelines, industrial inspection models, and various other ML systems for clients ranging from fintech startups to manufacturing companies. I've made mistakes, lost money on poorly scoped projects, and learned what it takes to deliver technical work on your own terms.

This is what I wish someone had told me before I started.

The Transition from Employee to Consultant

Most engineers assume the transition is about freedom—choosing your stack, your hours, your projects. That's true, but it's not the whole story. As an employee, you have a buffer between you and the business reality. PMs scope work, account managers manage clients, finance handles invoicing. As a consultant, you are all of these roles.

The first month is the worst. You realize that no one is sending you work. No one is managing your calendar. No one is making sure you're billing enough to cover your rent. The responsibility is clarifying and terrifying in equal measure.

The mindset shift is this: you are not selling your time, you are selling outcomes. Clients don't care about your CV or your favorite framework. They care about whether you can solve their problem and deliver something they can use. If you can't articulate what you're delivering in business terms—increased precision, reduced manual review, faster processing—you will struggle to close deals.

The other shift: you are always working, even when you're not coding. Business development, scoping calls, proposal writing, invoicing, follow-ups—these are not distractions from the real work. They are the real work. I track my time in two buckets: billable (client work) and non-billable (everything else). A healthy ratio for me is 60-70% billable. Below 50% and I'm spending too much time on sales. Above 80% and I'm not building enough pipeline for the next quarter.

Finding and Scoping Engagements

Most of my clients come from three sources: former colleagues, LinkedIn posts, and referrals from existing clients. Cold outreach has never worked for me. The conversion rate is effectively zero. What does work is visibility—writing about what you know, sharing case studies (anonymized), and making it easy for people who need your skills to find you.

The first conversation with a potential client is not about pricing. It's about understanding the problem. What are they trying to achieve? What have they tried? What does success look like? Most clients don't know what they need. They know they have a problem with unstructured data or manual processes or compliance risk, but they don't know whether the solution is NER, classification, RAG, or something else entirely.

Your job in the scoping phase is to translate their business problem into a technical solution they can understand and budget for. I usually send a scoping document after the first call that includes:

The scoping document is a forcing function for clarity. If you can't write down what you're delivering and when, the project is not ready to start. Most failed projects fail at scoping, not execution.

Pricing Strategies

There are three common pricing models: hourly, retainer, and project-based. Each has trade-offs.

Hourly

Hourly is the easiest to explain and the most flexible. You track your time, send an invoice at the end of the month. The problem with hourly is that it penalizes efficiency. If you finish a task in half the time because you're good at what you do, you make half the money. It also creates an incentive misalignment—you benefit from scope creep, the client doesn't.

I use hourly for exploratory work, proof-of-concept projects, and clients who are uncertain about scope. My rate is $150-200/hour depending on the project complexity and client budget. I bill in weekly increments to avoid surprises.

Retainer

A retainer is a fixed monthly fee for a defined scope of work. This works well for ongoing maintenance, model retraining, or advisory roles. The client gets predictable costs and priority access to your time. You get predictable income and deeper client relationships.

The challenge with retainers is scope drift. Clients assume that because they're paying a monthly fee, any request is covered. You need to define what's included and what's not, and track hours to make sure the arrangement is sustainable. I learned this the hard way with a client who initially engaged me for monthly model monitoring, then started asking for new features every week. The retainer quickly became unsustainable. We renegotiated after three months to a higher monthly fee with a clear scope.

Project-Based

Project-based pricing is a fixed fee for a defined deliverable. This is the most client-friendly option and the most profitable for you if you scope correctly. The client knows what they're paying up front, and you benefit from efficiency.

The risk with project-based pricing is underestimating the work. I always add a 30-50% buffer to my initial time estimate to account for unknowns, client delays, and scope changes. I also include a clause in the contract that additional features beyond the original scope will be billed separately.

For most projects, I quote a range rather than a fixed price: "This will be between $15k and $25k depending on final scope and complexity." This gives me flexibility while setting client expectations. After the scoping phase, I narrow to a fixed number.

Client Communication for Engineers

Engineers are trained to optimize for correctness and precision. Clients care about clarity and reassurance. This is a source of friction.

When a client asks "Is this going to work?", they don't want a detailed explanation of your model architecture or the limitations of transformer-based retrieval. They want to know: are you confident, what are the risks, and what happens if it doesn't work?

I've found that over-communicating is better than under-communicating. Weekly updates, even if nothing has changed. Screenshots, even if the UI is rough. Metrics, even if they're preliminary. Clients who don't hear from you assume the worst.

The other communication rule: bad news early. If you're going to miss a deadline, tell the client as soon as you know. If the data quality is worse than expected and the model won't hit the target metrics, say so immediately. Clients can handle bad news. They can't handle surprises.

Documentation is part of the deliverable, not an afterthought. Every project should include a handoff document that explains what you built, how to use it, and how to debug it when something goes wrong. If the client can't operate the system without you, they're going to call you at 3am. Write the documentation.

Managing Expectations and Scope Creep

Scope creep is the silent killer of consulting projects. It starts small: "Can you add one more field to the API?" "Can we test it on this other dataset?" "Can you build a quick dashboard so we can monitor this?"

Each request seems reasonable in isolation. Cumulatively, they double the time you spend on the project and eliminate your margin. The problem is that saying no feels adversarial, especially when you want to maintain the relationship.

The solution is to make scope changes explicit. When a client requests something outside the original scope, I acknowledge the request and offer two options: deprioritize something else, or extend the timeline and budget. This shifts the conversation from "can you do this?" to "is this worth the cost?"

Most scope creep comes from unclear requirements at the start. If the deliverables are vague, the client will continue to add features until they feel satisfied. This is why the scoping document is critical. Write down exactly what you're building. Get the client to agree. Refer back to it when new requests come in.

Building a Pipeline Without Sales Skills

I am not a salesperson. I don't enjoy cold calls, I don't like pitching, and I'm bad at small talk. But I've managed to build a sustainable consulting practice without doing any of those things.

The key is inbound interest. Make it easy for people who need your skills to find you. This means:

I post on LinkedIn once or twice a week about projects I'm working on, problems I've solved, or tools I'm using. The posts are short, technical, and specific. They're not salesy. The goal is to demonstrate expertise, not sell services directly.

About half my clients come from these posts. Someone sees a post about adverse media screening, realizes they have a similar problem, and reaches out. The conversation starts from a position of credibility because they've already seen my work. This takes time. I posted for six months before I got a single inbound lead. The first year is a grind. After that, the pipeline starts to compound.

The other half of my clients come from referrals. Every project should end with: "If you know anyone else who might need this kind of work, I'd appreciate an introduction." Most people are happy to make referrals if you've done good work. You just have to ask.

When to Say No

The hardest skill in consulting is turning down work. When you're starting out, every opportunity feels precious. Saying no feels like leaving money on the table. But taking the wrong project is worse than taking no project.

I say no to projects where:

Saying no preserves your capacity for better work. It also signals to clients that your time is valuable. If you say yes to everything, clients assume you're not busy, which undermines your negotiating position.

The other reason to say no: bad clients are a tax on your energy and reputation. If a client is difficult during the sales process, they will be worse during delivery. If they're pushing back on every estimate and questioning every decision, the project will be miserable. Trust your instincts.

Lessons Learned from Real Engagements

Every project teaches you something. Here are a few lessons that took me longer than they should have to learn:

First, always get a deposit. For project-based work, I ask for 30-50% up front. This filters out clients who aren't serious and gives you working capital. I've had two clients disappear after the first milestone. Both times, I had enough of a deposit to cover my costs.

Second, define done. What does it mean for the project to be complete? Is it a model that hits 90% precision? An API that handles 1000 requests per second? A deployment to production? If you don't define done, the project will never end.

Third, don't over-engineer. Clients don't care about your elegant architecture or your beautifully refactored codebase. They care about whether it works and whether they can use it. Ship the simplest thing that solves the problem, then iterate if needed. I've wasted weeks building features no one asked for because I thought they were technically interesting.

Fourth, track everything. Time, expenses, communications, scope changes. If there's ever a dispute, you want a record. I use Toggl for time tracking and keep a simple log of all client interactions. This has saved me multiple times when a client claimed I hadn't delivered something I had.

Fifth, build in buffer. Every estimate should include time for client delays, data quality issues, and unknown unknowns. If you estimate two weeks for a task, quote three. If you finish early, the client is happy. If you hit unexpected issues, you're still on time.

Finally, raise your rates. If you're booked out more than two months in advance, you're undercharging. If clients say yes to your first quote without hesitation, you're undercharging. I've raised my rates three times in two years. Each time, I expected to lose clients. Each time, no one cared.

Conclusion

Consulting is not for everyone. The uncertainty, the constant context switching, the need to manage yourself—it's exhausting. But if you value autonomy and want to work on a variety of problems without the politics of a large organization, it can be rewarding.

The transition from employee to consultant is as much psychological as practical. You have to get comfortable with selling your services, managing client expectations, and operating without the safety net of a salary. But if you can deliver good work, communicate clearly, and build a reputation, the work finds you.

The code is the easy part. Everything else is the job.