How I Scaled My Freelance Engineering Business with Maintenance Contracts

This article is a collection of the field notes from the moment I realized freedom was slipping, and what finally fixed it.

When the Applause Fades

As one of my high‑stakes data engineering projects wrapped up, the CTO was smiling. And he said, “This is exactly what we needed.” Their dashboards glowed green, the code was purring—and my invoice cleared right on schedule. Victory, right? Except two weeks later, I realised something unsettling: The moment I delivered what they wanted, they didn’t need me anymore. My income dropped to zero.

That wasn’t a fluke. Every freelance engagement ends in the same way: intense build, happy client, abrupt silence. If you dared to take a break, the sales funnel froze. Lowering your rate to win “one more” project only dug the hole deeper. You left corporate life to escape the treadmill, only to find yourself running harder on a new one.

If any of this feels familiar, read on. I found a way to maintain freedom and income by changing what I sell rather than how many hours I sell.

Why Traditional Freelancing Feels Like a Treadmill

Independent developers usually start with the promise of freedom—picking projects, skipping office politics, and taking vacations on their terms. In practice, they face two structural headaches:

• Rate‑driven race to the bottom. When your service (e.g., generic web work) is commoditised, clients shop on price. You can easily find typical examples of this kind on sites like Fiverr. The only lever you control is lowering your hourly rate, which forces you to work more hours just to pay the same bills. If you are living in a high-cost country like the US, it’s impossible to win this as more skilled, English-speaking talent joins from lower-cost regions.
• Insecure pipeline. A solo engineer can handle only one or two concurrent projects. Once a contract is wrapping up, you must sell again. Any downtime—whether a slow quarter or a family holiday—means zero engagement and a real risk of being forgotten. This means you are on a consistent run on the treadmill. You cannot get your mind off client acquisition even at the holiday beachfront.

These pressures quietly turn the promise of freedom into chronic anxiety and endless hours. Gut-wrenching, indeed! Let me share my failures before I finally transformed myself from an hourly worker to a business system owner.

Charging Premium Rates Helps, But It Doesn't Change the Game

In freelancing or consulting, the usual advice is “specialise and raise your rate.” There are highly paid professions like doctors or lawyers who charge by the hour, while others (cashiers, web designers, etc) suffer with low hourly pay. It helps to acquire specialized skills and niche down. For engineers, it could mean being an expert in cybersecurity or having ample experience in fintech.

But such an upgrade is necessary, but not sufficient. I’ll share two personal examples that show the limits:

• Failure #1 – Generic Retainer. I experimented with a monthly “access‑to‑my-knowledge” consulting retainer. I had many clients who valued the depth and width of my knowledge as much as my hands-on work. They came back to consult me from time to time after the initial project was done. So why not buy a priority seat that lets you be at the top of the wait list whenever they need my advice? Clients liked the idea—until budgets tightened. Retainers, viewed as discretionary, were among the first line items cut during a downturn.
• Failure #2 – One-Off Masterpiece, Zero Residuals. I was hired to design a streaming data system that few engineers could tackle. I billed at a high hourly rate and delivered exactly what they needed. Because the finished system was easy to run, their in‑house team took over. Revenue from that client dropped from premium to zero overnight. Specialization and niche down mean that not everyone is your customer, and it’s harder to persuade new prospects due to the high price tag.

In both cases, my value evaporated the moment the client no longer had a problem. They share a common flaw: payment stopped the moment perceived value stopped. The perceived value must continue to flow for them to keep on paying me. And the value must be on the critical path of their business operation, not just the “cherry on the top."

How would I ensure that? That's the million-dollar question. I'll explain how I reframed my value next.

Re‑examining What Clients Actually Buy

I went back to the drawing board and asked myself what clients were really buying. Was it just the code they paid for? After replaying all aspects of the client engagements, three things emerged—none of them were lines of code:

1. Data flows like a utility. Instead of manually updating a spreadsheet, what if the updated metrics are right there whenever you open a dashboard? Reliable, well‑organised data flowing daily, as predictable as water from a tap. People pay the monthly utility bill without questioning. Businesses do the same for fresh data.
2. Peace of mind. As an engineer, you all know no system runs without an issue forever. Software requires active monitoring and maintenance. Once the business realizes that it will start having concerns about how to keep the system up and running, it needs confidence that someone competent will fix the system whenever it breaks. It’s not about fear-mongering—it’s about awareness. Clients must recognize that no system runs flawlessly forever, and I'm here to assist.
3. Expertise on demand. Let clients have access to my knowledge whenever they need it. This seems to be rooted in hourly-rate thinking, but it does not if I combine it with #1 and #2: my knowledge works as a value multiplier, rather than just a commodity data plumber who fixes things. Business leaders want more than hands—they want trusted brains.

The guaranteed data flow and real-time troubleshooting, combined with expert knowledge access. After hours of self-brainstorming, this became the foundation for transforming my business into a maintenance model.

Now it's time to implement this framework and sell it. My journey of the business transformation has just started!

Defining the Service and the Scope

The hardest part of this exercise is sales, not engineering. Sales often sounds intimidating to engineers, but it starts by spelling out the obvious. I defined what the maintenance service is and the value it provides that suits my client's needs.

Freelance engineers often don't need to define their deliverables. They execute on what they are told, and the value is implied in the time spent. Consultants pitch their proposed solutions and estimated costs.

In the service model, it is typically referred to as a statement of work and service level agreement. But how do we create them? Here’s how I approached it.

Statement of Work

The statement of work (SoW) for a maintenance model should highlight the issues clients may not be aware of and suggest a service that continuously delivers the solution. It also needs to include the pricing structure that is not based on the hour spent. In my custom data pipeline maintenance, it touched the following points:

• Background: I was selling it to existing clients from the data system development, so I was well aware of their business needs. I wrote a brief paragraph to demonstrate my understanding, followed by my reasoning for why the business needed active monitoring and support.
• Anticipated Risks: I highlighted a few scenarios when an external factor, beyond the flawless (wink) system I built, could disrupt the data flow and affect their business operation.
• Solutions: Active monitoring and troubleshooting of the data system were my solutions. I outlined the system diagram, illustrating how anomalies are detected and alerted. Once the alert triggers, I promised to assess the impact and communicate it to the business stakeholders. Finally, I described the general process for recovering regular operation.

Service level agreement

When you are an hourly wage worker, you may get paid for the hours you worked, whether or not the service is delivered to the client's satisfaction...until you are fired. However, the service model must guarantee the delivery of the service, so what you guarantee matters. Writing a clear and explicit service level agreement (SLA) is essential.

In the service level agreement, I clearly answered the following questions and stated what's covered in the maintenance plan:

• What do I monitor, and how do I communicate the system's health to customers?
• How do I detect the abnormality, and what is the first response time?
• What is the recovery process, and how is the progress communicated?

The scope defined in the service level agreement not only clarifies what the customer can expect, but also protects me by clearly stating what is NOT covered in the agreement. For example, in my data pipeline service:

• The uptime is subject to the availability of the cloud service the customer subscribes to. If the data disruption is caused by the cloud platform (e.g., Amazon Web Services, Google Cloud), the service will not deliver the data until the cloud platform recovers from the incident.
• SLA does not cover the new integration requests. They must be estimated and billed separately.
• The SLA includes the version updates of the dependent software. However, engineering work is considered outside the scope of this SLA if there is a significant change in the integration. This includes the data source applications, data schema, or API specification.

As in the example above, it is crucial to clearly state when the service is inevitably disrupted. It is also essential to draw a boundary between SLA and new work to be charged separately.

Pricing and Invoicing

Pricing logic

I established a reasonable and straightforward pricing model, proposing a monthly fee per data integration. (That is, the sales increase as the client adds more use cases and integrations in the future...more about scalability later.)

I estimated the frequency of incidents and the labor required for recovery to determine the price. This does not have to be a precision science: The bottom-line price just needs to be high enough to cover the time spent on monitoring each day and the labor required to fix potential failures.

Competitive framing

The bottom-line price must be competitive. But what are you competing against? In my custom data pipeline case, an alternative for clients is to hire full-time data engineers to develop and maintain the system. What is the annual hiring cost in the market? I found that my pricing came out to just 10–20% of what it would cost to hire a full-time employee.

In addition to the lower cost, my service can deliver much faster than the hiring path: my service starts processing the data after just a day or a week of customization work.

One more note about pricing: The same amount of engineering work may result in a much higher value in a lucrative business. If you believe the perceived value is significantly higher than the bottom-line price, don't hesitate to raise it.

Scheduling the fee

Finally, schedule the fee as it is also your work to send the bill. None of the engineers I know enjoy sending out invoices to multiple customers manually every month. I'd give clients some incentive for contracting annually instead of monthly. Ensure the contract specifies that it automatically renews each year on a specific date and is billed accordingly.

Now that we have a clear service definition, it's time to sell it!

How to Sell Maintenance Contracts (Checklist)

Perfectly written SoW and SLA do not sell by themselves. But I'm not a sales professional. Sales professionals seem to possess a kind of magic—earning trust in seconds and closing with ease. How would I do that?

I still have no idea. So, I did what I could as an engineer: I started with the existing consulting clients who trusted me already because of the work I had done for them.

In essence, here is a checklist towards transforming the hourly contract to a service business:

1. Deliver first, earn trust. You must already be the engineer who built or rescued their critical system.
2. Confirm there’s no internal coverage. If they have an internal team to maintain the system, it's hard to sell. But they may be busy with other work and open for an external service.
3. Validate criticality. Ask bluntly: What breaks if this system stops for an hour? If pain is low, maintenance won’t sell.
4. Educate non‑technical stakeholders. Explain why software failure is inevitable and what proactive monitoring prevents.
5. Write a clear SoW and SLA. Define what is covered (monitoring, break‑fix) versus “new feature” work that triggers a separate statement of work.
6. Price by service delivery, not by the hour. It does not matter how little time you spend delivering the service. Ensure sales growth as the use case expands.

Once you've checked off everything and given some thought to your specific situation with the potential customer, it's time to talk to them. Don't start with a grand presentation, or they will understand nothing of the value you are trying to propose. Instead, ask something simple, like: "What's your plan for maintaining this system?" Let them speak first, and let the conversation flow naturally around the thinking points we already covered above. You won't need to "sell" in the sense of a sales professional's work with a trusting client.

Another advantage of starting with an existing relationship is that they are more likely to accommodate your terms, rather than treating you like a business transaction. Remember, the ultimate goal is to create an automatically renewing, continuous service contract. But we also must protect ourselves from becoming a hamster on a spinning wheel. You don't want to be on a pager duty without rest. You need to take vacations.

In my case, I ensured that I used the case of the data pipeline. The clients needed to check the data once a day for their internal operation, not customer-facing products. This gives more "wiggle room" in satisfying them without killing myself. Be cautious when selecting the right customers.

Congratulations, you have a new contract! Now it's time to deliver. The delivery of the work is also very different from hourly work. Let's take a look at it next.

Automating Delivery and Productizing Your Expertise

If you are an engineer who has successfully signed off on a maintenance contract in a way similar to how I did, I bet you are already skilled at delivering the results. Daily monitoring becomes a routine, and as a good engineer, you'd continuously improve it for a reliable system. A well-designed system makes you spend less time keeping promises to customers.

As the time requirements decreased, my capacity increased. It all started by templating the work. For example, there were common questions I asked new clients before integrating a new data source. Instead of writing on blank paper, I prepared templates. The template made my work easier and sped up the process for the clients.

I also scripted to automate the work. And it became more serious coding: Instead of writing the AWS deployment scripts from scratch for each integration, I coded to automatically generate them with minimum configuration. I also automated the system logging and alerting system. My system sends a data quality report to my inbox every morning. All of these automations helped to take my mind off the tasks while ensuring the quality of the service.

The improvements compounded. Clients got more value. I spent less time. It became increasingly reliable while using less and less of my time. Then, one day, I realized that everything I had coded could be integrated into a unified framework. That's when I rewrote everything into handoff core - a Command Line Interface (CLI) to develop and deploy custom data pipelines on a serverless platform (AWS Fargate).

Handoff began as an internal tool and then evolved into a platform. I wrapped the CLI with an Application Programming Interface (API) layer, then added a web application frontend. That snowballed into Handoff.cloud — a small platform that delivers customised data pipelines and their ongoing care. New prospects see a proven framework; existing customers fund continuous improvement; referrals arrive without the need for cold outreach.

Living the Scalable Lifestyle Business

Recurring revenue replaced feast‑or‑famine project income. Because core monitoring is automated, I schedule vacations without fear of disappearing. Clients stay engaged long after the initial build, and their expanding use cases grow the contract instead of replacing me.

Here is a quick takeaway of how I transformed from an hourly worker to a business owner with a maintenance business model:

• Premium hourly rates are necessary, but do not solve pipeline anxiety.
• Clients are happy to pay for peace of mind when the stakes are clear.
• A well‑defined maintenance offering turns finished projects into durable revenue and creates space to productise your expertise.

If freelancing still feels like sprinting on a treadmill, stop selling only your time. Sell the outcome clients really want: confidence that their software—and their business—keeps running while you finally enjoy the freedom you left your job for.

Next stop: Scalable Lifestyle Business

My maintenance contract evolved into Handoff.cloud, and it covers 10 to 20% of my business income, and it is growing every year without eating up my time. While Handoff.cloud doesn’t pay all the bills yet, it already ensures peace of mind; it gives an excellent cash flow to ensure the stability of my entrepreneurial life.

And the best part is that I didn't take an external investment, and I'm the sole owner. In my career, I worked with the founders of VC-backed startups. Some raised more than $100 million. Once they had investors, they often had to devote their lives to the startups, even sacrificing their personal lives and families. That was the opposite of the life I wanted.

While highly-paid Silicon Valley engineers start their week in back-to-back meetings, I start mine on a trail. One Monday morning, as the trees whispered and the sun broke through the leaves, a phrase came to me—“scalable lifestyle business.” I smiled because it wasn’t just a catchy idea. It was my reality.

Handoff.cloud gives me stability, freedom, and confidence. I didn’t raise capital. I didn’t sacrifice nights and weekends to chase exponential growth. I built it on my terms, with my skills, for clients I care about. And one day, my daughter looked up at me and said,

“Daddy doesn’t have to work much—his robots work for him.”

She wasn’t wrong.

If you’re still sprinting on the freelance treadmill, maybe it’s time to step off. Start small. Productize your expertise. Define the outcome clients really want—and deliver it without selling every hour of your life. That’s how you scale your freedom.

👋 I'm Daigo Tanaka. If you liked my story, follow me on LinkedIn to stay connected. You can also subscribe to my "𝐈𝐧𝐭𝐫𝐨𝐬𝐩𝐞𝐜𝐭𝐞𝐝 - 𝐑𝐞𝐟𝐥𝐞𝐜𝐭𝐢𝐨𝐧𝐬 𝐨𝐧 𝐓𝐞𝐜𝐡𝐧𝐨𝐥𝐨𝐠𝐲’𝐬 𝐈𝐦𝐩𝐚𝐜𝐭 𝐨𝐧 𝐃𝐚𝐢𝐥𝐲 𝐋𝐢𝐯𝐞𝐬" newsletter. I will deliver thought-provoking topics to your inbox.