Show the Manual Work Behind Your SaaS in Public

The short answer

Show the manual work behind your SaaS by naming what the user, software, and founder each do. Explain the handoffs and current delivery conditions beside any demonstration. Use the remaining manual judgments to form a specific public learning question, and update the account when the workflow changes.

Show the manual work behind your SaaS in public by naming what the user does, what the software does, and what still depends on you. Explain the handoffs, the current delivery conditions, and the next decision you want to improve. Keep those details beside any demo or announcement that could otherwise suggest automatic delivery.

A useful result can involve a founder preparing inputs, resolving an exception, or checking an output. Building in public gives you a way to explain that work and learn from it. Readers can offer better feedback when they know which part of the process they are looking at.

The practical question is how to describe today's service accurately while showing where the product is heading. A polished screen, a completed file, and a fully automated workflow are different things to account for in your update.

Give manual work a specific place in the story

Describe the task you perform before explaining why you perform it. “I map each customer's source fields before the import runs” tells readers more than “we offer hands-on onboarding.” The first statement identifies a dependency that affects how someone begins using the product.

In his July 2013 essay Do Things that Don't Scale, Paul Graham describes doing work manually before automating it and learning what to build through that work. This is startup advice from his experience, not a controlled study establishing that every manual workflow will succeed.

For a public founder update, apply the idea by making the current mechanism understandable. You might be learning which inputs vary, which judgments need context, or which exceptions recur. Say which uncertainty the manual work helps you examine.

Avoid turning the explanation into a vague promise that automation is coming soon. A concrete next question is more useful: can customers choose the relevant field mapping themselves, or do the labels require more explanation? That gives the audience a part of the work they can assess.

Map the handoffs before recording the demo

Write the workflow from the user's first action through the result they receive. Include work that happens away from the visible interface. A person may prepare a file before it appears on screen or release an output after the software finishes processing.

For each step, name the operator and the condition for moving forward. “The software produced a draft” and “the customer received the reviewed result” describe different points. If a person connects them, put that person in the account.

Keep the map short enough to use while writing the public post. Four questions usually expose the important boundaries:

• What must the user provide or decide?

• Which transformation does the software currently perform?

• What does a founder or teammate prepare, decide, or check?

• What is the user actually able to receive, change, or publish at the end?

This is an editorial method, not a maturity score. A workflow doesn't earn points simply because it contains fewer people. The map helps you identify the service you are offering and the claim a public demonstration can support.

It also makes missing steps visible. If you cannot explain how a draft reaches the customer, leave delivery as an unresolved part of the workflow rather than letting an attractive final screen imply it has been completed.

A fictional chapter tool shows the difference

Imagine Chapter Meadow, an invented SaaS tool helping podcast creators prepare chapter lists. The product, people, workflow, and example updates below are fictional. No customer session or product test was performed for this article.

Its founder wants to show a chapter list produced from a short interview clip. In this example, the founder still listens to the recording, chooses candidate chapter boundaries, and resolves speaker names. The software formats those prepared notes into an editable list. The creator reviews it and can export text.

The export does not publish chapters to a podcast host. The founder has not yet built a system that independently chooses every boundary from an arbitrary recording. Those limits change the meaning of the demonstration.

A title such as “Automatic chapters from any podcast” would overstate the invented process. It would attribute the founder's listening and selection work to the software, expand the supported input, and suggest a level of independence the example does not establish.

A more accurate public update could say:

Chapter Meadow currently combines founder-prepared chapter notes with software formatting. I choose candidate boundaries and resolve speaker names for the supplied clip; the app turns those notes into an editable list. The creator reviews the draft and exports text. Automatic boundary selection and publishing to a podcast host are not part of this version. I am investigating which boundary choices creators want to control themselves.

That is model wording for the fictional example, not a real founder testimonial. For your own update, describe the work you actually performed and the limits that apply to your current version.

Keep the recording faithful to the workflow

Show where the recording begins. If you have already prepared the input, explain that preparation before presenting the output. A screen recording can accurately demonstrate formatting while leaving the earlier selection process outside the frame, provided the caption names it.

If you skip a wait or combine several clips, explain the edit when it changes the apparent delivery process. You do not need to show an entire waiting period, but the recording should not imply that a founder-dependent step completed instantly and unattended.

Keep demonstrations and live availability distinct too. GOV.UK's prototyping guidance explains that code prototypes can resemble live services while differing from production systems. Its government-specific guidance also takes care to prevent prototypes being mistaken for real services. The relevant lesson for a SaaS update is to label what the audience is seeing.

Describe a prototype as a prototype, a prepared sample as a prepared sample, and a currently delivered workflow in its actual terms. Don't invite readers to rely on a service path that exists only in a demonstration.

The guide to turning a public SaaS demo into useful feedback offers a complementary distinction: what you showed, what people said, what users tried, and what changed. Naming the manual steps makes the first part of that record more precise.

Tell prospective users how the service currently runs

When the post includes an invitation, explain the practical dependency on a person. State what someone submits, how the handoff is arranged, what they receive, and where they can ask about an exception. Use delivery conditions you can actually support.

For Chapter Meadow, the founder might arrange a specific review session for a short sample clip. That is a different offer from an unattended upload service accepting recordings at any time. The public invitation should let a creator recognize which experience is available.

A screenshot of a completed chapter list doesn't answer questions about turnaround, supported inputs, or how much assistance is required. Put the relevant conditions near the next action, where someone decides whether to take part.

The SaaS beta invitation guide explains how to make the user, task, effort, support, and limits explicit. Connect that invitation to the current workflow rather than making readers assemble a new promise from old posts.

Sharing the mechanism doesn't require publishing customer recordings or internal access details. Use invented demonstration material or material you are entitled to share. Keep your public explanation focused on the work and its boundaries.

Use the manual work to form the next product question

Look for the decision you repeatedly make, not just the action you repeat. Clicking the same button several times might be easy to automate. Deciding which of two chapter boundaries is useful may require understanding how a creator intends listeners to navigate the episode.

In the fictional example, the founder could record why a candidate boundary was chosen and what the creator changed. A creator moving a boundary to include the setup of an answer suggests a different question from a creator only shortening the chapter title.

Keep those observations in their own terms. An edited title is evidence of an edit in that session. It does not establish that every creator wants the same wording rule or that the software can now make the decision independently.

A public follow-up might describe the problem category without exposing the recording: “The next design question is whether a chapter should start at the question or at the answer. I am preparing controls that let creators choose.” That gives relevant readers a specific tradeoff to discuss.

The GOV.UK Service Standard's whole-problem guidance considers how responsibilities and services join into a user journey. Applying that lens here helps you follow the task beyond a single screen. It is a design analogy for this article, not a requirement imposed on SaaS founders.

Use the feedback to decide what to investigate next. You may automate formatting, improve the creator's controls, or retain a human review step. Public learning is useful when the decision follows from the task, rather than from pressure to make the product sound more autonomous.

Update the public account when one step changes

When you automate part of the workflow, say which dependency changed and which remains. In Chapter Meadow's imagined next version, the app might propose candidate boundaries while the founder still checks them before the creator sees the draft. That would be a new capability with a continuing review step.

The update should describe both. “The app now proposes boundaries; I still review them before delivery” preserves the current operator at each stage. A broader announcement that chapters are fully automatic would skip the remaining dependency.

Keep the older demonstration dated and connect it to the newer explanation. Someone arriving through an earlier post should be able to tell that it shows founder-selected boundaries. A change in one step need not make the whole history misleading if the transition is clear.

Evaluate the result separately from the implementation change. Removing a manual step does not, by itself, establish better chapter quality, faster customer completion, or lower operating cost. Measure the particular outcome before adding it to the claim.

For your next public update, choose one workflow that still needs your involvement. Name that involvement, show the useful result, and ask about the decision that remains difficult. That gives your audience an honest account of progress and a concrete way to help shape what comes next.

Questions founders ask next

Should every internal task appear in a public update?

Include the tasks that change how a reader understands the demonstrated capability, delivery conditions, or required assistance. Keep the explanation proportionate. A full internal operations log is unnecessary when a short account of the relevant handoffs answers the user's question.

Can a paid SaaS offer include manual help?

Describe the actual offer, including the assistance, scope, delivery conditions, and what the customer receives. Manual work alone does not tell you whether the offer fits a buyer's needs. Avoid presenting founder-dependent delivery as unattended automation.

What if the manual step is temporary?

Describe it as part of the current workflow until it changes. State the next development question without promising an unsupported delivery date. When you remove or alter the dependency, publish a follow-up explaining the new scope and any remaining checks.

Sources

• Paul Graham: Do Things that Don't Scale — historical startup advice about manual delivery and learning before automation; July 2013.

• GOV.UK Service Manual: Making prototypes — distinguishing realistic prototypes from live services; checked November 13, 2026.

• GOV.UK Service Standard: Solve a whole problem for users — considering the whole journey and responsibilities; checked November 13, 2026.

• Buildside Journal: Public SaaS demos and useful feedback — separating presentation, response, observed use, and decisions.

• Buildside Journal: Writing a SaaS beta invitation — setting expectations for a bounded product test.

Frequently asked questions

A note from Uriel Bitton

I share practical lessons from building Buildside and learning alongside SaaS founders.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading