The Small Tasks That Hold a Business Together

A booking button looks simple. Behind it sits a promise: someone will perform a particular service, under particular conditions, at a time the business has agreed to honor.

Designing that button raises questions the screen cannot answer by itself. What work is included? Who can do it? What information do they need? What happens if the request changes? How does the business know the work has been accepted?

Those are the questions I want to document while building Lily Property Care. I am developing its operations alongside a website and client portal, using AI-assisted development, including Lovable. My priorities are understanding labor, improving booking, and making sound decisions about cost.

The portal is launching. No clients have used it yet. This is an account of the thinking behind the build, with its benefits still to be tested.

Read the accompanying research paper: From Friction to Capacity.

01Start with what the service requires

Before deciding what software should do, I need to understand what the service requires people to do.

That includes the physical work, but also the information and decisions surrounding it. A service description needs to become something a person can carry out. A client requirement needs to reach the person responsible. A change needs to be understood before someone acts on an outdated instruction.

Onboarding at Lily has been manual. The next step in documenting it is to make its actual steps and decisions explicit. I do not want to assume that putting the same activity into a form automatically improves it. The form needs a purpose: what information does it collect, who uses it, and what action does it support?

That is also where the cost question begins. If the work behind a service is unclear, a more convenient way to book it does not resolve the uncertainty about what delivering it will require.

02Small does not mean unimportant

Consider an illustrative task: confirming what a client wants included in a service.

It might involve a short exchange. But the result can affect the assignment, the instructions, the resources required, and what the client expects at completion. Its importance comes from the work that depends on the answer.

The same is true of confirming availability or recording an exception. These activities connect people and decisions. A business process needs those connections to be understandable, especially when someone other than the founder must act.

Coordination research offers a useful way to think about this. Malone and Crowston describe coordination through dependencies among activities. Their framework helps explain why examining the links between tasks can be as important as examining the tasks themselves. It does not tell us which software Lily should build, but it gives us better questions to ask. [1]

For each small task, I want to understand what starts it, who owns it, and what becomes possible when it is finished. If nothing useful depends on it, removal may be worth considering. If it carries an important decision, making it explicit may deserve attention even before we know how many minutes it consumes.

03Make the process understandable before automating it

An explicit workflow does not need to begin as a complicated diagram. It can begin with a clear statement of the input, the action, the responsible person, and the expected result.

Take booking. A request and a commitment may need different treatment. If employee job acceptance becomes part of Lily’s system, the design will need to answer what acceptance means and what happens when nobody accepts. A screen should represent those decisions clearly.

These are possibilities under consideration, not descriptions of features already operating at Lily.

There is also room for improvement without automation. A clearer service definition might resolve uncertainty. A consistent instruction format might make information easier to use. Removing an unnecessary question might make onboarding easier. Software should be considered alongside these options.

My concern is that a feature can become an extra obligation. Somebody has to enter the information, keep it current, and know what to do when it is wrong. The reason for building it needs to be strong enough to justify that work.

04Where AI belongs in the build

AI assistance is part of how I am developing Lily’s technology. It can participate in the work of specifying and implementing a tool, while I remain responsible for deciding what the business needs.

Three things should stay distinct. AI can help build software. Software can automate a defined action. A process can improve because its steps are clearer. Those contributions may occur together, but they are not interchangeable.

An automatic notification is not necessarily an AI function. A better description of the service is a business decision. And code that produces a working screen still needs to be checked against the behavior the business intends.

My intended approach is to work incrementally: understand the existing system, make a focused change, and verify it. I want the record to preserve what was requested, what changed, what needed correction, and why. That will make the development history useful beyond a collection of finished screenshots.

05A booking carries a labor commitment

The connection between labor and booking deserves particular attention. Making it easier to submit a request is only one part of designing a useful booking process.

The business also needs to understand the requested work and the conditions under which it can be performed. If a service changes, someone needs responsibility for reviewing the implications. If work is assigned, the person doing it needs usable information.

The same care applies to cost effectiveness. Custom software has costs beyond getting the first version working. Purchased software has tradeoffs beyond its subscription price. Setup, training, maintenance, integrations, and recovery all belong in the decision.

I have not established which approach is most economical for Lily. A simpler manual process, configured software, and custom development all deserve consideration against the actual work. A branded portal is not evidence that building everything ourselves is the right choice.

06Completion should mean something clear

For Lily, my stated criterion for successful completion is client approval. The way we obtain and record that approval still needs to be defined.

That creates a practical design question: how should the business distinguish work submitted for review, work accepted, and work requiring correction? What happens when the client has not responded?

A status label should not conceal those differences. Nor should client approval replace the business’s own quality review. The process needs room for human attention when expectations or conditions require discussion.

I want technology to help make those responsibilities clear. Whether it actually does so will depend on implementation and use.

07What this research contributes now

The accompanying Liquid paper documents an early stage of this work. It sets out the questions guiding the build and distinguishes proposed improvements from demonstrated results.

There are no established time savings, customer benefits, or capacity gains to report. The useful record now is why a task deserves attention, what alternatives were considered, and how a decision becomes a process or a tool.

Another business owner does not need to copy Lily’s portal to use that approach. Choose one activity that connects a promise to delivery. Explain what it requires, who is responsible, and what happens next. Then consider whether the best change is to remove a step, clarify it, standardize it, buy support for it, or build something specific.

A small task is worth examining when important work depends on it. Documenting that relationship gives the build a reason to exist, and gives later evaluation something concrete to examine.

Read the accompanying research paper: From Friction to Capacity.