Should You Offer a Service Before You Build the Software?

Offer a service before you build the software when the work lets you learn a repeated customer problem, charge for a valuable outcome, and keep the scope narrow enough to productize later. Do not offer services just because you are avoiding the harder question of whether the software itself deserves to exist.

The useful question is not “Can I sell custom work?” It is: “What will this service teach me, what part should become software, and what rule tells me to stop taking work that cannot generalize?”

Key takeaways

• Sell a defined outcome to a narrow customer group, not open-ended help.
• Choose engagements for the product knowledge they create as well as the cash they bring in.
• Record the repeated inputs, decisions, exceptions, and outputs while you deliver the work.
• Productize the part that repeats; refuse work that pulls you away from the problem you want to own.
• Set a review date and an exit rule before service revenue makes custom work feel safe.

What should the service teach you?

Imagine Maya wants to build software that turns messy inventory files into weekly purchasing recommendations for small manufacturers. She could spend four months building imports, dashboards, permissions, and alerts. She could also sell a tightly scoped “weekly inventory review” in which she receives the files, cleans them, explains the risks, and sends a recommendation.

The service is useful only if Maya treats every delivery as a learning instrument. She should record which files arrive, where the data breaks, which decisions the buyer actually makes, what information is missing, and which recommendation changes an order. The work should expose the customer’s real workflow before she turns her guesses into features.

YC’s advice on doing things that do not scale describes manual recruiting and hands-on delivery as ways to learn what early customers need. Steve Blank’s customer-development guide from Stanford makes a related point: early founders test assumptions with customers and look for people who have a painful problem, an existing workaround, and a budget.

The service earns its place when it puts you inside the problem often enough to see a pattern that a market report or a feature brainstorm would miss.

Define the smallest paid offer

Do not start with “We do anything related to inventory.” Write one offer with a clear customer, input, output, timeframe, and price. Maya might promise one weekly review for one facility using a defined file format, delivered by Friday, with one call to discuss the recommendation.

That boundary protects both sides. The customer knows what they are buying. Maya can compare engagements instead of treating every project as a new consulting business. She can also notice when a prospect wants something outside the learning goal.

Keep a delivery log with five fields:

1. What input did the customer provide?
2. What manual step consumed the most time?
3. What judgment or exception was required?
4. What output did the customer use?
5. What part could another customer share?

The last question matters. A request is more promising when it appears across similar customers and leads to the same useful outcome. One customer’s special report may be good consulting and weak product evidence.

When does service work become a trap?

Services can produce revenue while hiding the absence of a product customers will buy without your people attached. A recent account of services before product-market fit makes the distinction directly: the work created value because it revealed repeated integration problems, but it became dangerous when bespoke delivery stopped producing new learning (Digital Reflections).

Set the rule before you get busy. Maya might review every four engagements and ask:

• Did at least two customers have the same core problem?
• Did the same manual step recur often enough to describe clearly?
• Did the customer pay for the outcome rather than merely praise the idea?
• Can the repeated part be delivered with fewer decisions next time?
• Would a product make the result faster, safer, or more consistent?

These are operating questions, not universal benchmarks. If the answers stay vague, keep researching or stop. If the work keeps changing by customer, you may have a service business rather than evidence for software.

Productize the part that repeats

Maya should not automate everything she does. She should isolate the bottleneck that recurs and matters to the customer. If file cleanup repeats, she might build an importer. If the recommendation depends on a judgment only she can make, software may not be ready. If the customer mainly values the weekly decision meeting, a service may remain the right product.

Protect ownership and capacity before building. Which reusable tools belong to Maya? Which customer data can be retained? What is explicitly custom? What happens when the service ends? A product path can disappear if every useful artifact is locked inside a one-off contract or if delivery leaves no time to build.

When should you wait?

Wait on a service when you cannot name the customer, problem, or outcome, when delivery would create regulated or safety-critical obligations you cannot support, or when every prospect wants a different business. Wait when the service is only a way to avoid asking someone to pay for the proposed product.

Offer the service when it gives you paid access to a real workflow, a bounded promise, and a clear learning plan. Then revisit the plan on a date you choose. The goal is not to make custom work look like software. The goal is to earn the right to build software from repeated, paid evidence.

FAQ

Is a service business a failed software startup?

No. A service can be the right business, or it can be a temporary discovery and funding model. Decide based on the customer outcome and the economics you want, not on the label.

How many service customers do I need before building?

There is no universal number. Look for a repeated problem, comparable workflows, paid outcomes, and a part of delivery you can describe without exceptions. Set a threshold before you start so enthusiasm does not become the only evidence.

Should I call it a productized service?

Use the label only if the offer has a defined scope, repeatable delivery, and a clear customer outcome. A new name does not make custom work repeatable.

Wrap up

Before writing the first line of software, write the service offer, the customer problem, the delivery boundary, the five fields you will log, and the rule that ends or changes the experiment. Sell the smallest useful outcome, learn from the work, and productize only what repeats.

If you want peers to pressure-test the offer and the productization rule, bring the experiment to the buildpurdue cohort.