The dangerous moment in a services-to-software business is not the day you decide to build a product. It is the day you turn down a paying client because you are sure the product will make up the difference. A full calendar makes that decision feel urgent. A growing signup count makes it feel justified. Neither tells you whether next month’s bills will get paid.
Mailchimp began as a side project at a web design agency; Basecamp grew out of work at the design firm 37signals. Those origins are useful reminders that client work can finance a product. They are not instructions to quit services on a particular date. If you want to make the transition without investors, you need to manage two scarce resources separately: cash and hours.
Establish the cash floor before you change the calendar
Start with a monthly number below which you will not willingly take receipts. Include business expenses, a sustainable owner draw, and a provision for taxes. If those amounts are $3,000, $4,000, and $2,000, your operating floor is $9,000 a month. The tax figure is an example, not a recommended rate; set yours with an accountant who knows your situation. Keep the tax provision in a separate account so it cannot quietly become product-development money.
Now count cash you actually expect to collect, not proposals, contracted annual value, or invoices you sent yesterday. Suppose you collect $12,000 a month from services and $2,000 from software subscriptions. That is $14,000 against a $9,000 floor: a $5,000 surplus. The surplus is what funds experimentation and a buffer. The $12,000 service line is not proof that you can afford to abandon services.
Make a one-page, 13-week cash forecast. Put expected client payment dates and subscription payouts on the left; put payroll, hosting, contractors, taxes, and your draw on the right. Update it every Friday from your bank and payment processor. If one client pays 30 days late, the forecast should show which week gets tight. A monthly profit-and-loss report may say the business is healthy while the checking account says otherwise.
Before permanently reducing client commitments, aim for six months of the $9,000 floor—$54,000—in accessible cash, excluding money reserved for taxes. You do not have to wait for that balance to begin building software. You do need to distinguish a low-cost experiment, such as reserving an afternoon each week, from a lasting reduction in income. If your buffer is smaller, make smaller, reversible cuts.
Find the hours that can actually become product time
Client work has a way of filling every hour you do not defend. For two weeks, record your time in plain categories: client delivery, client sales and administration, product support, product development, customer conversations, and everything else. Include the ten-minute interruptions. Do not build an elaborate tracking system; a calendar and a daily tally are enough.
Say you want to work 45 hours a week. You currently spend 24 hours delivering client projects and five hours on client sales and administration. Product support takes another five. That leaves 11 hours for development and customer discovery if you respect the limit. If a new client project requires 12 hours a week, you cannot accept it and still call the product a priority. You would be borrowing against evenings, support quality, or both.
Reserve recurring blocks for product work before you seek more service bookings. Make them specific: Tuesday and Thursday mornings for building, Friday morning for customer calls. Track planned versus actual hours for a month. If you routinely lose those blocks to “urgent” client requests, the problem is not discipline. Your service commitments have no slack, and the product schedule is fictional.
Calculate the cash contribution of each client alongside the hours the client consumes, including meetings, revisions, and collections. A $3,000 monthly retainer that reliably uses ten hours a week is different from one that takes four. This is not an invitation to drop the most demanding client immediately. It tells you which engagement to narrow, re-scope, or decline at renewal when the cash math permits.
Build a product from repeated work, not one loud request
Your client roster can reveal a useful software problem, but it can also trap you in custom development. Look for a task you perform repeatedly for different customers without changing the underlying workflow each time. Document the input, the recurring decisions, and the output. Then talk to five customers or prospects about the problem before committing a quarter to a build. Ask what they do today, how often they do it, and what happens when it goes wrong.
The test is not whether people compliment the demo. Ask for a paid pilot with a narrow scope and a defined end date. For example, offer to replace one weekly reporting task for three customers over six weeks. Write down what the product will do, what you will still do manually, and which requests are out of scope. Money collected for a pilot is stronger evidence than a waitlist entry, but it is not recurring product revenue unless the customer keeps paying.
Keep pilot delivery hours visible. If three customers pay $300 a month each but require 15 hours of your time every week, you have created a small service business with a software interface. That might be a worthwhile bridge, but name it accurately. Record product receipts and the hours required to earn them. The goal is to see whether support and onboarding become more repeatable as customers arrive, not merely whether revenue rises.
This is where the agency origins of Mailchimp and Basecamp are most instructive. Client work exposed their founders to problems worth solving, while the product had room to become something distinct from an individual client’s project. Your version may be much smaller. You do not need their eventual scale; you need evidence that a second customer can get value without commissioning a second custom build.
Reduce services one commitment at a time
Once the product has paying customers, make the transition in steps rather than announcing that you are “going all in.” Return to the $14,000-in, $9,000-out example. If a $3,000 monthly client engagement ends, receipts fall to $11,000, assuming software stays at $2,000. You still have a $2,000 monthly surplus. That is a manageable experiment if your cash forecast and buffer support it. It is not a reason to drop another client next week.
Give each step a review period—say, 90 days. During it, protect the hours you reclaimed and compare them with results: paid activations, subscription cash collected, cancellations, support load, and your bank balance. If those ten freed hours a week dissolve into scattered maintenance, you have learned something important. Fix the operating bottleneck before cutting more service income.
Suppose you eventually want to reduce services from $12,000 to $6,000 a month. With a $9,000 floor, $3,000 in software receipts would theoretically cover the difference. That leaves no margin for refunds, late client payments, or a slow sales month. A more durable checkpoint is $5,000 in software receipts alongside $6,000 in services: $11,000 total, preserving a $2,000 surplus at the same illustrative expense level.
Use cash collected and a trailing three-month view for that checkpoint, not a single strong launch month. Check customer concentration, too. If one company accounts for half your software receipts, losing it can reverse the transition overnight. Set a written rule before emotions enter the decision: do not reduce the next service commitment unless the forecast stays above your floor and your buffer remains intact after the cut.
Change the kind of service work you accept
You do not have to choose between a packed agency and zero client work. A narrower service offer can support a product far better than open-ended projects. Prefer engagements with a defined deliverable, clear revision limits, and a predictable payment schedule. Avoid selling your permanent availability. One client who expects an instant reply can fragment every product-development block on your calendar.
For existing clients, have the conversation before their next renewal. You might say that you are moving from ongoing implementation to a monthly review and a fixed number of support hours. Show them what will remain available and what will end. Some will leave, which is why you model the cash effect first. Others may value the clearer arrangement. Do not promise your software will replace services until it genuinely can.
Keep a short list of acceptable bridge work: projects you know how to deliver, can invoice promptly, and can schedule around product commitments. A two-week implementation with a deposit and a firm completion date is easier to plan around than a vague six-month partnership. If cash falls below your floor, that list gives you a way to earn without rebuilding the same all-consuming client business you meant to leave.
Set a stop rule as carefully as an exit rule
Not every service-funded product deserves years of subsidy. Decide in advance what would cause you to pause it. One reasonable test is whether, after six months of consistent protected work, you can identify customers who pay, keep using the product, and require less founder time per account than your earliest pilots. The exact customer count depends on your market; the pattern matters more than an arbitrary MRR milestone.
Watch for the less visible failure mode: product receipts rise while total owner hours rise faster. If $4,000 in monthly software revenue requires 25 additional hours a week of manual work, you have not yet bought yourself freedom from services. You have added a second delivery queue. Simplify onboarding, narrow the product, or stop accepting the use cases that demand bespoke help before chasing the next sale.
Write down your response to three cash scenarios now, while you are calm:
- Above the floor with a growing buffer: keep the current service load and invest scheduled hours in the product.
- Above the floor but drawing down the buffer: pause further service cuts and investigate churn, payment delays, and product support hours.
- Below the floor in the 13-week forecast: stop discretionary product spending and seek a defined, short-term client engagement.
Review those rules monthly with actual figures. The point is not to make the transition risk-free; it is to keep a disappointing month from forcing a desperate decision. A service business that reliably funds experiments is an asset, not an embarrassment. Let the product earn more of your calendar and your income in measurable increments. You can build something durable without making your bank account absorb every optimistic assumption.
Leave a Reply
You must be logged in to post a comment.