The first version of a useful software business may contain very little new software. It can begin with a person taking an input, applying a repeatable method, checking the result, and delivering an outcome someone values.
That manual work is informative when the offer is clear and the delivery record is honest. It is misleading when the builder calls every successful custom project proof that a scalable app is ready.
A concierge minimum viable product is a bounded way to learn about customer value and delivery before automating the mechanism. This chapter of The AI Software Factory, in the SalarsNet AI section, asks what to do manually, what to record, and when the evidence justifies software.
The process described here is proposed. It does not report an executed Salars service, customer payment, or automation saving.
Choose a result small enough to deliver
A concierge offer should solve one recognizable task. “We will improve your business with AI” leaves the customer unable to inspect the promise and the operator unable to define completion.
A hypothetical offer could transform one supplier file into an agreed import format. Another could prepare a reviewed product listing from specified intake information. A third could organize a set of customer questions into a response draft queue. Each has inputs, outputs, limits, and a review point.
Choose a result whose value does not depend on an imagined future platform. The customer should be able to use the output now under the stated conditions. If the service produces only a demonstration of what software might eventually do, it tests interest in a demonstration rather than the operational result.
The payment-validation chapter examines whether an authorized buyer accepts a defined offer. Concierge delivery examines what happens after acceptance: which work repeats, which exceptions matter, and what the customer actually uses.
These two forms of evidence belong together without being collapsed. A purchase tells you something about willingness to pay. Successful delivery tells you something about the mechanism and burden. Repeat use adds evidence about recurring value.
Make the manual delivery visible
Explain that people will perform or review the work. This sets accurate expectations about timing, capacity, and exception handling.
Manual delivery is not a defect in an early offer. It can provide judgment and flexibility while the team learns. The problem is presenting it as an autonomous system and allowing customers to depend on a capability that does not exist.
State who does what. The operator might normalize data, apply rules, and review flagged records. The customer might confirm ambiguous item identifiers before using the output. A third-party tool might perform a mechanical transformation. Keep these responsibilities distinct.
The customer does not need a tour of the team’s internal tools. They need the facts that affect their decision and use of the result: what they supply, what they receive, what requires review, and what happens when the input falls outside scope.
If an AI tool assists delivery, apply the same standard. Do not assume its output is correct because it is fluent or because the first example worked. Review the consequential fields using criteria that do not depend on the model’s own confidence.
Use a structured intake
The first intake can reveal more than the first output. Customers may not have the required records, may use terms differently, or may need help understanding the task boundary.
For a hypothetical supplier-file service, ask for the original file, desired output format, allowed transformations, and examples of ambiguous fields. Use permitted copies and collect only information needed for the task. Avoid requesting live credentials when a sample file can answer the immediate question.
A structured intake should preserve uncertainty. If the customer cannot identify the authoritative product code, the operator should not guess silently. The output can flag the field and ask for a decision.
Record intake work separately from processing work. Ten minutes transforming the file may depend on an hour clarifying its meaning. Automating the ten minutes does not eliminate the hour.
The UK Government Digital Service recommends examining how users currently work and including the needs of people who support the service. Applied here, that suggests observing intake and handoffs rather than evaluating only the final artifact. This is a commercial inference from public-service guidance. Learning about users and their needs.
Separate mechanical work from judgment
As delivery proceeds, classify each step by what it requires. Mechanical work follows a clear rule on defined inputs. Judgment resolves ambiguity, prioritizes competing aims, or determines whether the rule applies.
Renaming a known column can be mechanical. Deciding whether two similar item descriptions refer to the same physical product may require judgment. Checking that every output row has a source identifier can be mechanical. Deciding which source is authoritative when records conflict needs a policy and possibly customer confirmation.
This distinction should be observed in real delivery rather than imposed from an automation wish list. A task that looks mechanical can contain hidden exceptions. A judgment task can become partly structured once the team identifies a reliable decision rule.
Keep a delivery log with input conditions, steps, time, exceptions, corrections, and final customer use. Avoid recording unnecessary private content. The log should show what the operator did and why, not merely that a job was completed.
The useful question becomes: which repeated steps can software perform under an explicit contract, and which decisions should remain reviewable? The answer defines an automation boundary.
Count exceptions without treating them all as failures
An exception can be an expected part of the service. A missing item code may be handled by flagging the row for customer review. That is different from silently inserting the wrong code.
Classify exceptions by cause. Input outside scope, unclear customer instruction, missing information, tool failure, and operator mistake require different remedies. Combining them into one error count conceals the mechanism.
Some exceptions justify improving intake. Others justify narrowing the promise. Some can be handled by a reusable rule. Others indicate that the service requires skilled judgment and should be priced accordingly.
Record successful exception handling as well as incorrect outputs. A system that safely stops when it lacks information may be more useful than one that always returns a complete-looking result. The customer still needs to understand what stopped and how to proceed.
Do not claim an accuracy rate from a handful of favorable examples. A local record can establish what happened in the observed jobs. Broader reliability requires representative cases and a defined measure. The testing strategy chapter develops that requirement; the concierge log supplies candidate cases.
Measure the full delivery burden
A manual service reveals work that a prototype often omits: explaining the offer, obtaining the input, clarifying meaning, checking the result, responding to questions, and correcting misunderstandings.
Include that work in the economic record. A hypothetical $150 job might require two hours of processing and one hour of communication. At an assumed planning value of $30 per hour and $15 in direct expenses, the illustrative contribution before acquisition and fixed overhead is $45.
If the customer needs another two hours of corrections, the same example becomes negative $15. These values are hypothetical, not current prices or measured Salars outcomes. The calculation shows why output generation alone is an incomplete cost measure.
Separate learning work from recurring work, but do so conservatively. Designing a first intake form may be mostly one-time. Explaining inconsistent supplier fields may recur with every customer. A founder’s hope that support will vanish is not evidence.
The SBA’s cost and break-even guidance helps frame the difference between revenue and the costs required to supply it. The precise software service model still needs its own inputs and classifications. Startup costs and break-even analysis.
Deliver an inspectable artifact
A concierge result should give the customer a way to understand what changed. For a transformed file, include the output, a short account of applied rules, and a list of unresolved rows. Preserve the connection to the original input so disputed values can be traced.
Avoid returning a polished artifact that hides ambiguous decisions. A complete-looking spreadsheet can be more dangerous than a visibly incomplete one if the operator filled gaps with guesses. The customer needs to know which fields are supported, which were transformed mechanically, and which require their judgment.
Use a simple completion check before delivery. Does the output have the agreed structure? Can each record be connected to its source? Are excluded or unresolved inputs identified? Has a reviewer checked the consequential fields? These criteria should come from the offer, not be invented after seeing a favorable output.
The check can remain lightweight for a low-impact task. Its purpose is to make the promise concrete. A more consequential output requires controls appropriate to the decision it influences.
Also provide a clear correction path. The customer should know how to identify a problem and what information the operator needs to investigate. A correction request can become valuable discovery evidence when recorded without blame or unnecessary personal information.
If the service later becomes software, these artifact and correction conventions can carry forward. They define part of the product contract before a user interface exists. That is a practical advantage of manual delivery: the team learns what evidence the customer needs alongside the output, rather than discovering that obligation after automation.
Ask what the customer did with the result
Delivering a file is not the same as improving the customer’s task. They may never import it, may correct it extensively, or may use it only because the operator helps at every step.
Follow the result into use. What current work did it replace? Which review steps remained? Did it arrive when needed? Did the customer trust it enough to act? If it was not used, what prevented use?
Ask about a recent occurrence rather than a general opinion. “What happened with the file we returned on Tuesday?” can reveal the handoff. “Would you like an app that does this?” may produce another polite endorsement.
A useful observation can be a narrower benefit than expected. Perhaps the output did not save import time but made discrepancies easier to inspect. That could justify a different promise. The operator should revise the offer honestly rather than continuing to advertise the original saving.
Record the customer’s account separately from the team’s interpretation. A customer may attribute success to the service while other conditions changed. The concierge trial is evidence about a specific delivery under specific conditions; causal claims need a suitable comparison.
Automate one repeated step at a time
When a step repeats across appropriate cases and has a clear contract, consider a small automation. Preserve the manual method as a baseline while checking whether the software maintains correctness and reduces the relevant burden.
For the hypothetical file service, the first automation might validate required columns and flag missing fields. The next might apply a known mapping. It need not immediately perform live import or resolve ambiguous identities.
Use difficult cases from delivery, including rejected inputs and exceptions. Keep some later cases outside development so the team can check transfer after changing the implementation. If a held-out case is used to tune the rule, label it development evidence and obtain a fresh evaluation case.
Success should include the output requirements and the human review burden, not merely execution speed. A fast transformation that creates more correction work has not improved the service.
This is a proposed bounded comparison, not an executed automation experiment. It would require actual jobs, independently specified expected outcomes, and recorded results before the team could claim a local improvement.
Know when the service should remain a service
Some tasks retain substantial judgment or customer-specific work. That can support a valuable service business even when full automation is unrealistic.
A team should compare delivery models honestly. A service may allow higher prices and closer customer relationships while limiting capacity. A self-service product may require standardized inputs, better onboarding, and more robust failure handling before its lower price makes sense.
The important distinction is the promise and economics, not prestige. Calling custom work a platform does not make it repeatable. Calling an operator’s judgment inefficient does not show that software can replace it reliably.
If the customer-specific work is the source of value, automate supporting steps and preserve the judgment. If repeated mechanical work dominates and the exceptions can be bounded, a software product may become more plausible.
The existing service-first, software-later chapter examines this business progression more broadly. Concierge delivery here supplies the operational evidence needed to choose the next mechanism.
Avoid endless custom exceptions
Early customers often ask for additional outputs. Some requests reveal a shared need. Others create a separate project under the same price.
Record each request and its effect on delivery. Does it recur within the intended segment? Does it fit the core task? Does it change the required data, responsibility, or support? Can it be offered separately?
A customer willing to pay for custom work can be valuable. The team should decide whether to operate that service deliberately. It should not count every custom purchase as evidence that one common app has demand.
Scope boundaries protect both sides. The customer understands what the price covers. The operator can complete the work and learn from it without inheriting an undefined obligation.
A stopping condition might be that every new customer requires a substantially different workflow. That result suggests narrowing the segment, changing the offer, pricing a service, or closing the product hypothesis. It does not mean the manual work was wasted; it means the work revealed the actual business.
What Would We Do at Salars?
A proposed Salars concierge trial would take one bounded operating task and deliver it with existing tools and human review. A supplier-file transformation is an illustrative candidate, contingent on actual evidence and authorized inputs.
The team would state the manual nature of the work, use structured intake, and log processing, clarification, exceptions, correction, and customer use. It would keep payment evidence distinct from delivery evidence and report the full burden.
After several suitable cases, the team would identify one repeated mechanical step for a small automation comparison. Correctness, exception handling, and review work would be evaluated against the manual baseline. Difficult and later cases would remain protected until evaluation.
If the value depended on continuing custom judgment, the proposal would remain a service with terms that fit the work. If a common contract emerged, the team could invest in a narrow application. No such trial or saving is asserted in this article.
The concierge method earns its value by exposing the work beneath the promise. Once that work is understood, software can be built around a task the customer actually needs done.
Sources
- Government Digital Service: Learning about users and their needs, official guidance on current workflows, needs, and supporting roles.
- U.S. Small Business Administration: Startup costs and break-even analysis, official economic framework.
Sources inspected October 7, 2026. The concierge process, automation comparison, and Salars application are proposals. Examples and costs are hypothetical, with no executed customer or effectiveness result claimed.
Loading comments…