From Friction to Capacity

This paper documents the reasoning behind Lily Property Care's developing processes and tools. It is an initial process-design and development account, written while the business's operations and software are being shaped together. It describes questions and proposed design responses, not demonstrated results.

Abstract

This paper examines the questions involved in translating a small service business's manual operations into explicit workflows and supporting software. Lily Property Care, positioned by its founder as a premium property care business, is developing its operations alongside an integrated website and client portal using AI-assisted development, including Lovable. At the evidence cutoff, onboarding is manual, the portal is launching, and no clients have used it. The current contribution is therefore a preliminary design account rather than an evaluation of effectiveness. Drawing on founder statements and selected literature, the paper considers labor, booking, cost effectiveness, task dependencies, and client approval. It distinguishes AI assistance in development from deployed software automation and improvements that require no software. Small tasks are examined as points where information, responsibility, and service commitments connect. A lightweight development record is proposed to preserve decisions, alternatives, implementation evidence, and revisions. The account provides a basis for documenting the build without claiming demonstrated savings, customer value, or increased capacity. Subsequent study can examine whether the resulting processes and tools justify their operating and maintenance costs.

Introduction and research questions

A booking interface can capture a request without establishing whether a business can fulfill it. A completion button can record an action without establishing whether the client accepts the work. These illustrative distinctions expose the central problem addressed here: designing the relationship between a service promise and the work required to deliver it.

Lily's development provides an opportunity to document that reasoning while the business's processes and software are being shaped together. The immediate question is: How is a small service business translating manual operations into explicit workflows and an integrated software system, and what reasoning guides those choices? The longer-term question concerns whether those choices reduce friction, preserve quality, and increase capacity.

“Operating system” refers here to connected workflows, responsibilities, information, and software. It does not describe a computer operating system or an autonomous business. Operating capacity means the ability to fulfill service commitments with available resources under acceptable conditions. Growth in bookings or revenue would not, by itself, demonstrate improved capacity or more economical operations.

Business context and development stage

Alenn owns both Lily Property Care and Liquid. According to the founder, Lily targets premium property care, onboarding has been performed manually, and the technology project includes a website and client portal. Development involves AI assistance, including Lovable. The portal is launching, but no clients have used it. Employee scheduling and job management, potentially including worker acceptance of jobs, remain areas under consideration.

The founder identifies labor, understanding labor, booking, and cost effectiveness as present priorities. Client approval is his stated criterion for successful job completion. The mechanism for obtaining and recording that approval has not been established in the research record.

Earlier discussions addressed portal visibility, welcome materials, scheduling, and connections between client-facing information and internal operations. These establish development interests, not implementation outcomes. No job dates, property specifications, prices, or staffing arrangements are used as case evidence. No current code, deployment, or operational records were inspected for this manuscript. The account consequently concerns the founder's reported position and proposed design reasoning.

Relevant literature

Malone and Crowston (1994) frame coordination in terms of dependencies among activities. Their framework addresses relationships such as shared resources and the use of one activity's output by another [1]. For Lily, this provides a way to ask what a task enables and who depends on its completion. It does not establish that Lily has a particular coordination failure or that a portal would resolve one.

The Lean Enterprise Institute describes standardized work as precise procedures that remain subject to continuous improvement [2]. Its account is rooted in production processes, including work sequence and inventory. Lily should not import those manufacturing constructs uncritically. The relevant design lesson is narrower: an explicit description of current work can become something people inspect and revise. This is an adaptation proposed for the case, not evidence that a manufacturing method has been validated in property care.

The OECD's The Digital Transformation of SMEs identifies barriers including skills gaps, financing, and limited interoperability [3]. Its broad analysis supports considering organizational readiness and integration alongside software functionality. It does not supply a benefit estimate for Lily or resolve whether custom development is preferable to a purchased product.

Evidence on AI-assisted development also requires contextual interpretation. Becker and colleagues' 2025 randomized study involved experienced developers working in familiar open-source repositories and reported longer task completion times when AI tools were allowed [4]. METR's February 2026 follow-up described selection and measurement problems that complicated interpretation of a newer experiment [5]. Neither setting directly represents this founder's use of Lovable. Together, the reports caution against treating perceived helpfulness as a verified productivity effect.

Parasuraman and Riley (1997) distinguish use, misuse, disuse, and abuse of automation [6]. Their analysis motivates attention to the relationship between people and automated functions. Applied here, that means asking who reviews outputs, handles exceptions, and remains accountable. These sources form a focused conceptual background, not a systematic literature review or proof of the case's hypothesis.

Case-study approach and evidence boundaries

The project is intended as a longitudinal, single-business founder case study. This initial paper is an opening account, not a completed longitudinal analysis. Formal documentation was established during the development discussion; no earlier research protocol is assumed.

The immediate case evidence comprises founder statements and an explicit correction of the research emphasis. An initial proposal foregrounded job-level measurement. The founder redirected the work toward documenting the build, understanding processes, and explaining the significance of small tasks. This is a documented research-scoping decision, not an operational intervention or a measured result.

Future records will distinguish reported experiences from inspected artifacts, tests, deployment evidence, and actual use. Proposed, built, tested, deployed, and used describe different milestones. A screenshot may establish an interface's appearance, while leaving permissions, reliability, and adoption unresolved.

A short record for each substantive change should connect its date and source to the task, reason, alternatives, decision, implementation, and validation. It should distinguish founder contributions from AI contributions and preserve unresolved issues. Where a change is abandoned or revised, the earlier reasoning should remain visible. No documented failed implementation is available for this account, so none is reconstructed.

This approach prioritizes a traceable account over extensive reporting. Business-effectiveness measurement is deferred. Functional testing remains part of responsible implementation.

Understanding labor before encoding the process

The founder's emphasis on labor establishes the starting point for design. Before a form or scheduling rule can represent a service, the business needs a usable account of what it is committing to perform. A service name alone may leave important questions unanswered: what is included, which conditions change the work, and which decisions require consultation?

For this case, a useful proposed distinction separates physical service labor, administration, and coordination. Physical labor performs the service. Administration maintains the information and records around it. Coordination aligns scope, people, resources, and commitments. These categories need not become separate software modules; they help prevent a design from making one category easier by creating hidden work elsewhere.

Consider an illustrative property requirement recorded during onboarding. If the information affects service delivery, its purpose extends beyond completing a form. Someone must be able to find, understand, and apply it when doing the work. Its relevance may change, and a person must be able to correct it. These are proposed questions for Lily's process design, not observed failures in its current onboarding.

The same reasoning applies to cost effectiveness. An easier booking experience cannot establish a viable price if the labor commitment remains unclear. The first design objective is therefore to make relevant obligations understandable. Precise cost models can develop as the business learns; unsupported numerical assumptions should not be embedded merely because software makes calculation possible.

Small tasks and the dependencies they carry

A task's duration is only one reason to examine it. A brief confirmation can establish whether another person may proceed. A recorded correction can change the instructions that govern later work. The proposed analytical unit is consequently a task together with its inputs, responsible person, output, and downstream use.

An illustrative scope confirmation shows the distinction. The meaningful output is agreement about the service, rather than evidence that a message was sent. A workflow could deliver messages reliably while leaving the underlying scope unresolved. Designing around the intended outcome helps clarify what the software should represent and where a person must decide.

Five possible treatments follow. An unnecessary task can be removed. A confusing task can be simplified. A recurring activity can be standardized. A sufficiently defined action may be automated. A judgment-sensitive activity may remain human. These are alternatives to consider, not a sequence requiring every task to become automated eventually.

Standardization should also have limits. A common information structure may be useful while the service itself varies. A required field that does not influence a decision could impose burden without a clear purpose. The development question is what each task contributes to the work, including whether its contribution justifies asking someone to perform it.

AI-assisted development and implementation reasoning

Three mechanisms need separate treatment. AI assistance can contribute to design discussions, specifications, code, or revision. Deployed software can execute defined rules and move information. A clearer process can improve work without new software. Lily's founder reports AI-assisted development, but the evidence does not establish the contribution of each mechanism to particular features or outcomes.

This distinction matters when explaining a future change. If a notification runs on a fixed rule, its execution is ordinary automation even if AI helped write the code. If the founder clarifies the information needed before confirming a service, that is a process decision. An interface may support the decision without having originated or validated it.

The founder's intended discipline is incremental: inspect the architecture, make bounded changes, protect existing data and functionality, and check behavior. This is a stated approach, not a verified description of every development action. For an illustrative future job-acceptance feature, useful checks could include conflicting acceptance attempts, withdrawn assignments, and access restricted to appropriate users. These are proposed tests, not tests reported as passed.

AI-generated output still requires operational evaluation. The founder must decide whether a proposed workflow fits the service, whether its language is understandable, and what happens when reality differs from the assumed path. Technical review must address behavior beyond the visible screen. A polished interface alone does not establish correct permissions, reliable state changes, or recoverability.

The build record should preserve why a change was requested, what the AI supplied, what the founder accepted or corrected, and what evidence supports its status. That makes development an inspectable sequence of decisions rather than a retrospective story assembled around finished screens.

Booking, cost effectiveness, and human judgment

For design purposes, booking is best treated as a commitment with prerequisites. The proposed questions concern what must be known, who may confirm it, and what happens when conditions change. A request, a confirmed service, and an accepted assignment could be distinct states. This is a possible representation, not a description of Lily's current database.

Worker acceptance introduces further decisions. Availability does not necessarily establish suitability, and displaying a job does not establish that someone owns it. If Lily develops this capability, the founder will need to define how acceptance interacts with responsibility, reassignment, and unfilled work. These decisions should guide interface behavior instead of being inferred from a generic booking template.

Cost effectiveness must include the obligations created by both the service and the tool. Relevant categories include labor, development effort, subscriptions, training, support, maintenance, oversight, and recovery when the process fails. At this stage these are categories for reasoning, not reported expenditures. A seemingly inexpensive feature may require continuing attention; a purchased product may cost more in subscriptions while reducing other work. The comparison remains open.

Client approval adds a separate completion question. A proposed workflow might distinguish work submitted for review, client acceptance, and a requested correction. The business also needs a deliberate response when approval remains outstanding. Silence should not be represented as approval merely to simplify a status display. Internal quality review remains a separate responsibility: it addresses whether the business has met its own requirements before asking the client to accept the work.

Exceptions and service recovery should retain a clear human owner. Software can make information available and preserve decisions, but the appropriateness of a response depends on the service relationship and the circumstances.

Build-versus-buy tradeoffs and intended differentiation

An integrated Lily interface is one possible response to the founder's priorities. Alternatives include a simpler manual process, a standardized document, configured software, or connected purchased tools. A fair comparison begins with the same task and requirements. Otherwise, a custom design may be compared with an unsuitable product configuration and appear preferable by construction.

The comparison should consider setup, workflow fit, integrations, training, maintenance, data export, and vendor dependence. Custom development can still depend on external hosting, databases, authentication, and development platforms. A branded interface does not establish ownership or control of every underlying component. No detailed product comparison has been performed for this manuscript.

Differentiation requires similar discipline. A capability must first be established. A difference from competitors requires an identified comparison set and current evidence. Customer value requires evidence from customers. These claims cannot substitute for one another. Lily's intended differentiation may concern how care and information are connected, but portal availability alone would not show that clients prefer its approach.

Premium positioning likewise expresses an intended service standard. A process design should consider whether it makes communication and responsibility clearer, rather than assuming that more client interactions signal better service. A portal that requires unnecessary input could work against the experience the founder wants to create.

Current documented position and unresolved questions

The supported position is limited but useful. The founder is developing operations and software together, reports manual onboarding, and is launching a portal without prior client use. He has prioritized labor, booking, cost effectiveness, and client approval. He has explicitly selected build documentation as the immediate research focus.

The design discussion makes several dependencies available for examination: scope to labor, information to instructions, booking to responsibility, and completion to acceptance. Their relevance to particular Lily features must still be established through workflow descriptions and implementation evidence. The exact onboarding sequence, architecture, approval mechanism, and feature status remain unresolved.

The present contribution is therefore a framework grounded in the founder's stated priorities, plus a transparent statement of where the record ends. It is not an audited implementation history. As build artifacts are added, later versions can replace hypothetical examples with dated decisions and technical evidence.

Limitations and subsequent evaluation

The founder is both participant and author, with commercial interests in the businesses discussed. Selective recall and enthusiasm for the build may influence what is documented. This initial account contains no independent operational observations, customer feedback, or controlled comparison. Its conceptual proposals should not be generalized as demonstrated practices for all service businesses.

Deferring measurement allows the present work to concentrate on development, but limits what can later be inferred about the original manual process. Historical savings cannot be reconstructed confidently from an incomplete record. Subsequent evaluation can examine adoption, quality, administrative effort, and total cost using records proportionate to the business.

Any later before-and-after comparison will need to consider changing scope, staffing, experience, and demand. Released time is not automatically realized profit or additional capacity. Its actual use would matter. These are later evidentiary questions, not conditions that prevent the founder from clarifying processes and building carefully now.

Conclusion

Lily's current case illustrates a research opportunity at the point where service knowledge is being translated into workflows and software. The useful contribution at this stage is to make the reasoning visible: what work is promised, which tasks connect it, where responsibility lies, and why a particular change is proposed.

Small tasks are relevant because of the decisions and dependencies they carry. AI-assisted development is part of the reported build approach, while process design, automation, and human judgment remain distinct. Documenting their relationship creates a basis for later assessment without presenting intended benefits as achieved results. Whether the developing system increases capacity economically remains an open question.

Ownership and AI assistance disclosure

Alenn owns Lily Property Care and Liquid and has a commercial interest in both. The case relies on his reported context and priorities. AI assistance was used to research, structure, and draft this manuscript, and the founder reports AI assistance in software development, including Lovable. The paper is self-published by Liquid and has not been peer reviewed. No identifying client or employee material is included.