How We Built Pest-Control Software With AI

Start with two people doing different jobs

The project is a field-service application for pest-control companies. Office staff need to manage customers, schedule visits, assign technicians, and review reports. Technicians need to open a visit on a phone, register arrival, record findings and photos, report product usage, and finish the service.

The first prompt made that distinction architectural. It asked for two independent React and TypeScript web apps: a desktop-oriented Admin and a mobile-first technician app. Both use a Supabase backend and shared business contracts. The interface is in Spanish; the repository documentation is in English.

One instruction captured the product intent particularly well:

Do not make it look like an admin dashboard squeezed onto a phone.

That is a useful constraint because it explains what the separation is for. Sharing database types reduces inconsistency. Sharing every screen or interaction would make it easier to forget that the technician is doing a different job.

The bootstrap also had a firm stopping point: authentication, organization membership, shared types, reproducible local setup, and checks. Visits, signatures, reports, inventory, and offline support were explicitly deferred. The foundation had to work before the next prompt added business behavior.

Even then, the follow-up requests were practical: give me separate commands to start each app, make development login easy, and make local setup repeatable. Those small improvements reduced the effort required to inspect each later change.

Make each prompt end in a demonstration

The next assignment was Visit Lifecycle Foundation. It began with the phrase “At the end of this task we should be able to demonstrate,” followed by the path from creating a customer to seeing a technician’s arrival in Admin.

This gave the agent a result that crossed the database, permissions, and both interfaces. A visits table alone would not satisfy it. A convincing mobile screen with no saved arrival would not satisfy it either.

We extended that path in stages: persistent findings and photo evidence; product usage; customer review and acknowledgement; then PDF reports and email delivery. Recurring plans, technician invitations, and business onboarding followed as additional workflows.

The order mattered. A report needs reliable completed-service data. A signature needs a clear record of what the customer reviewed. Inventory deductions need a usage record they can trace back to a visit. Building those dependencies first made each later assignment more concrete.

The prompts also kept an online MVP boundary. Offline synchronization, billing, fuel tracking, and advanced analytics stayed outside the early work. That boundary let us examine the service path without taking on every adjacent product problem.

What the detailed prompts actually contributed

The implementation briefs were long. Their useful content fell into four recurring parts: existing context, an observable outcome, rules that must remain true, and evidence required at the end.

Existing context meant reading the repository instructions, relevant feature documentation, migrations, and both frontends before changing code. Later prompts repeatedly asked the agent to preserve the architecture and avoid re-scaffolding unrelated modules. Each task was an extension of a growing product.

An observable outcome translated feature names into actions. “Technician management” became inviting someone, letting them access Mobile, assigning work, and eventually deactivating them while retaining service history. That exposed decisions a generic create/edit/delete request would leave unresolved.

Rules that must remain true covered the difficult cases. A technician must not access another company’s data. Retrying a completion must not create a second final revision. Updating a finding later must not rewrite an earlier service record. These requirements gave the implementation something more precise than “make it secure and robust.”

Evidence made completion reviewable. The briefs called for migrations that could run from scratch, permission checks, frontend tests, browser demonstrations, and updated documentation. The evidence was attached to the behavior being built.

My reading of these prompts is that their value came from resolving ambiguity. Their length was a consequence of the decisions they contained. Repeating the technology list was less valuable than explaining what should happen when a customer is absent or a save is retried.

A signature needs a stable service record

The completion prompt shows why that specificity mattered. “Add a signature pad” sounds like a small interface task. In this product, it raised a bigger question: what exactly is the customer acknowledging?

We defined completion around a saved revision of the service. The technician reviews the customer-facing information, records a signature, absence, or refusal, and finalizes the visit. The system preserves the reviewed content. Later changes to live findings do not silently change that completed record.

The prompt turned this into a concrete check:

Verify completed revision still contains original finding snapshot.

That sentence connects a data-model decision to an observable result. The implementation also checks whether the reviewed data changed before completion, and identical retries return the original result. Internal notes remain separate from the customer-facing content.

Report generation then builds on that revision. The PDF uses the saved customer-facing service content. Email delivery has its own status and retry process, so a later delivery failure does not undo a completed visit.

These boundaries made the workflow easier to reason about: completing the work, generating its document, and delivering that document are related events with different failure cases.

The inventory prompt was precise—and too ambitious

The original inventory brief asked for a ledger of stock movements, warehouse receipts, allocations to technicians, receipt acknowledgement, and usage deductions. A following brief added physical counts and reconciliation. Together, they described a system that could track both quantity and custody.

The problem appeared during my review of the interface. Inventory items were created in one place, quantities managed in another, and a warehouse concept appeared without an obvious setup flow. I asked where the items were defined, then why the warehouse was needed.

The requirement I restated was smaller: Admin defines products, units, and quantities; technicians record usage inside visits; company stock updates automatically. The revised acceptance example was simple enough to check without explaining the architecture:

That required changing more than labels. Usage had been deducted from technician stock. The simplified implementation needed one company balance, correct adjustments when usage changed, protection against duplicate deductions, and a migration that preserved history without counting internal transfers twice.

We kept the useful accounting foundation and removed the custody workflow from the everyday interface. Admin can add products with initial quantities, replenish stock, correct quantities with a reason, and inspect history. Technicians record what they used during the service.

This is the part I would change in the planning process. Before commissioning allocations and reconciliation, I would walk through one ordinary day with the simpler flow and ask whether knowing who holds unused stock is necessary for the first release. A detailed prompt can make an untested assumption expensive very quickly.

A passing build did not finish the work

The implementation history records checks at several levels: frontend behavior, database permissions, complete browser flows, and PDF inspection. Those checks answered different questions. A successful build could not establish that another company’s records were inaccessible, or that a repeated submission preserved the original service evidence.

The report-delivery task explicitly recorded that local email sends were simulated. Later production signup attempts exposed sender-domain configuration and email-rate-limit problems. Those were real release issues even though the application had passed local checks.

That distinction belongs in the story. The records support a working implementation and documented validation of particular flows. They do not establish customer adoption, field reliability over time, or that every production dependency was ready at every step.

The same applies to mobile testing. A phone-sized browser preview helps inspect the layout; the early visit task still listed physical-device camera testing as outstanding. Keeping those limits visible made the next action clearer.

The brief I would reuse

For another project, I would keep the structure and make the product assumption explicit before detailing the implementation. This is a condensed template based on this project’s workflow, rather than a verbatim original prompt:

Read the repository instructions and the relevant
implementation, migrations, and feature documentation.

Outcome:
Describe one user workflow we can demonstrate end to end.

Product assumption:
Explain why these steps are needed in the first release.
Identify anything we still need to validate with the user.

Scope:
Name the behavior to add and what is deferred.
Preserve the existing architecture and unrelated features.

Rules:
Define permissions, state changes, historical records,
and behavior after duplicate or failed submissions.

Evidence:
Demonstrate the workflow. Check relevant failure cases.
Run the required checks and update the documentation.
Distinguish local validation from production verification.

Stop when this workflow is complete and reviewable.

I would then use the result before asking for the next layer. In this project, the short follow-up about inventory changed the product more meaningfully than another page of implementation instructions could have.