Asher's Blog

Founders are naturally attracted to automation because automation looks like the business they hope to build. It promises speed, scale, consistency and lower operating costs. The manual version can feel temporary and unimpressive by comparison, as though the company has not yet begun the serious work.

I have learned that doing the work by hand before automating it can be one of the most intelligent ways to build. The manual process teaches you what the product must actually do, where customers become confused, which exceptions occur repeatedly and what part of the service creates enough value to deserve software.

This is a variation of the familiar advice to do things that do not scale. The qualification I learned the hard way is that unscalable work needs both a time limit and a scale limit. A manual process can be an excellent teacher at the beginning and a dangerous operating model later. You should know what you are learning from it and what evidence will tell you that it is time to build something more scalable.

Automation multiplies whatever you already understand

When a process is clear and well designed, automation can make it faster and more reliable. When the process is confused, automation can make the confusion faster and more difficult to change.

Teams sometimes automate a workflow because it consumes too much time, without first asking why the workflow exists or whether each step is necessary. The result is software that faithfully reproduces an inefficient manual process. The company has spent engineering resources to preserve complexity.

Performing the work manually exposes the decisions hidden inside it. An employee may appear to be copying data from one place to another, but observation reveals that they are also correcting formats, identifying duplicates, interpreting incomplete information and deciding when an exception requires escalation. If the company automates only the visible data movement, the resulting system will fail in all the places where human judgment had quietly held the process together.

The manual version therefore acts as research. It allows the company to document the actual workflow rather than the imagined workflow.

Manual work brings founders close to the customer

Early in a company’s life, distance from the customer is more dangerous than inefficiency. A founder who personally onboards customers, prepares reports or resolves unusual requests receives information that may disappear once the work is divided among departments.

The customer’s hesitation becomes visible. The founder hears which words require explanation, where information is unavailable and which promised benefit matters enough for the customer to tolerate inconvenience. These observations influence not only the product but also pricing, positioning and support.

Many successful products begin with a service hidden behind a simple interface. The customer experiences a useful outcome while the team completes much of the work manually. This allows the founder to test whether the outcome is valuable before investing heavily in automation.

The important ethical boundary is honesty. A company should not misrepresent a manual process as fully automated if that difference affects security, speed, privacy or the customer’s decision. The purpose is to learn and deliver value, not to create a false impression of technical maturity.

The exceptions are the specification

The normal path is usually easy to imagine. A customer submits complete information, every system responds correctly, approvals happen on time and the transaction succeeds. Software built only around that path will look impressive during a demonstration and disappoint customers in real life.

Manual operation reveals the exceptions: duplicated records, missing documentation, delayed responses, unusual approval structures, interrupted payments and customers whose established workflow does not fit the assumed sequence. Some exceptions are rare and should remain manually handled. Others appear often enough to become product requirements.

This distinction is difficult to make from theory. If the team tries to automate every imaginable edge case, development becomes endless. If it ignores every edge case, the product remains fragile. Manual experience helps the company estimate frequency, consequence and the value of automation.

The best product specifications are often records of repeated human decisions. When the team sees the same exception being resolved in the same way, it has found a candidate for a rule, tool or automated workflow.

Manual first does not mean careless first

A manual process can still be structured, secure and auditable. This is especially important when dealing with payroll, financial transactions, compliance or personal information.

The company should define who can perform the work, what approvals are required, where information is stored and how every important action is recorded. Manual should mean that human judgment remains involved, not that employees improvise without controls.

In fact, designing a disciplined manual process can make later automation better. The team has already clarified roles, data, decision points and escalation rules. Engineering is not being asked to convert chaos into code; it is translating a process that has been observed and improved.

The company should also measure the manual process. How long does each case take? Where do errors occur? Which steps create waiting? What volume can one person safely handle? These measures will help determine what to automate first and whether the automation actually improves the system.

Give unscalable work a time limit

The phrase “do things that do not scale” can become an excuse for allowing temporary methods to survive long after their learning value has declined. Teams grow accustomed to heroic manual effort, and founders postpone investment because employees continue finding a way to make the process work.

Every manual experiment should have a review date. At that point, the company should ask what it has learned, whether the customer need is validated and whether continuing manually remains safe and economical.

A time limit does not mean that the process must be automated by a predetermined date regardless of evidence. It means the organisation cannot allow the temporary method to continue invisibly. The decision to extend it must be conscious and supported by a reason.

This protects employees as well as the business. Manual processes often rely on people working late, remembering exceptions and carrying operational knowledge in their heads. What feels flexible to the founder can become exhausting for the people performing it every day.

Give it a scale limit as well

Time is not the only trigger. A process that is safe for ten customers may become dangerous at one hundred, even if the company reaches that volume much faster than expected.

Define the maximum number of customers, transactions or cases the manual system can handle without compromising accuracy, response time or control. Watch for early warning signs such as growing backlogs, repeated errors, slower reconciliation and dependence on a small number of employees.

The scale limit should be determined by risk, not merely inconvenience. If a mistake could affect customer funds, employee salaries or regulatory obligations, the company should migrate before the process reaches its theoretical maximum. Capacity should include room for unusual demand and failure recovery.

Founders sometimes wait until the manual operation breaks before approving automation. At that point, the team must redesign the system while managing a crisis. The better time to build is when demand is sufficiently validated and the existing process still has enough stability to teach the engineers what good performance requires.

Automate the constraint, not everything

The first automation should address the part of the process limiting quality or growth. That may not be the task employees dislike most.

One repetitive step may consume time but create little risk, while another short step creates most errors and customer delays. Mapping the process helps the company identify the real constraint. Automating the wrong step may make one employee faster without improving the customer outcome.

Sometimes the best intervention is not full automation. A validation tool, internal dashboard, template or alert may remove the most dangerous part while preserving human judgment where it remains valuable. The choice should follow the evidence gathered during manual operation.

The company should also resist automating a process merely because technology is available. Artificial intelligence can now perform tasks that previously required substantial human effort, but technical possibility does not establish customer value. Automate because it improves speed, accuracy, cost or experience—not because the feature will sound impressive in a presentation.

Preserve human understanding after automation

Once software takes over a process, teams can gradually lose their understanding of how it works. Employees know which button to press but cannot explain the underlying decisions or recognise when the output is wrong.

This is dangerous in important systems. The company should retain documentation, auditability and people who understand the process deeply enough to investigate exceptions. Automation should reduce unnecessary effort without making the organisation helpless when the system encounters something new.

The manual version gives the company an operational memory. Preserve it in rules, incident records, training and system design. Otherwise, future teams may repeat the same discoveries that produced the automation in the first place.

Learn by hand, then earn the right to scale

The manual version is not a sign that the company lacks ambition. It can be evidence that the founder respects the problem enough to understand it before encoding assumptions into software.

Do the work personally or close enough to observe it. Record the decisions, exceptions, time and risks. Use the process to verify that customers value the outcome, then identify the point at which continuing manually would harm the service or constrain growth.

Doing things that do not scale is useful only while the unscalable work is creating knowledge the company has not yet captured. Once the learning becomes repetitive, the business must convert it into process, technology or trained capacity.

Start manually so that you build the right thing. Set a time limit so that temporary methods do not become culture. Set a scale limit so that growth does not turn learning into danger. The goal is not to remain manual; it is to automate only after you understand what deserves to be built.