Built and launched in about two weeks
We built Falconbill with AI-assisted development and launched it into production in about two weeks. We did not recruit a five-person development team for the build.
A/B tests and Google Ads experiments
We also ran A/B tests and Google Ads experiments without hiring a separate marketing department. These activities do not establish a conversion lift or a return on advertising spend; no such result is claimed here.
Traditional-team budget scenario
For scale, a traditional build by five U.S. developers over two to three months would cost roughly $144k–216k: the BLS May 2024 median software-developer salary of $133,080 a year, prorated by month, plus an assumed 30% overhead.
Illustrative staffing budget, not a project quote or measured savings. It does not deduct our own delivery costs.
The job and its paperwork in one record
Falconbill is a phone-first web app for US tradespeople, solo operators, and teams of up to five. It connects clients, jobs, estimates, and invoices. A tradesperson can prepare a quote on site, keep visits attached to the job, issue an invoice, and follow payment status between jobs. The business purpose is to carry the details of the work into the documents used to approve and pay for it.
The product runs in a browser without an app-store installation. That suits a workflow in which the person inspecting the work may also be scheduling the visit and preparing the bill. A phone is useful at the point where the details become known, rather than only when the owner returns to a desk. Falconbill also describes support for multiple businesses on its higher individual plan.
In a common manual counterpart, a service request might begin in a message, the site details in a contact record, and the estimate in a separate document. The owner would have to carry the address, scope, and agreed amount between them. This is a general example of the administrative burden the product addresses, not a reported history of a particular Falconbill customer.
The problem becomes more specific when a customer has several properties. The person paying can stay the same while the location, unit, and work change. An accurate customer name on an invoice does not by itself establish which job is being billed. Falconbill's connected records make the relationship between the customer, the location, and the commercial document part of the working process.
The product walkthrough below follows one illustrative job through Falconbill's features and the choices an owner makes when using them. It is not a measured customer outcome.
Identify the customer, site, unit, and job
Suppose a small trades business is asked to quote a repair in one unit of a property managed by an existing customer. That customer also has work at another site. The owner would first identify the customer responsible for the request and the property where this repair belongs. The unit number would narrow the location further, so the visit and quote could refer to the same place.
Falconbill supports multiple properties, sites, and unit numbers. This keeps the work location separate from the person or business paying. A property manager can remain the customer across several jobs without forcing every job into a single address. The relationship is useful later when an owner needs to understand whether two documents concern the same work or two separate properties.
The job would describe the requested work at the selected unit. A visit would describe an occasion on which someone attends to it. Falconbill connects jobs and scheduled visits with the commercial records, and visits can be assigned to workers. The distinction matters because arranging an inspection and agreeing a price answer different questions. A scheduled visit does not itself tell the customer what the business will charge.
For this illustrative repair, the owner could assign the inspection while keeping the job attached to the correct site. The worker would need enough location information to attend the intended unit. If the request named only the customer, the owner would have to resolve the location before relying on it for the visit or estimate. Connected records are most useful when the initial identification is correct.
A later return visit could concern the same repair without creating a second commercial scope. Conversely, a different request from the same property manager could be a separate job. The owner would decide which relationship reflects the work.
Carry observations from the visit into the quote
Workers can add photos on site, alongside the product's job and visit workflow. In the example, a photo could help the owner understand the condition the worker inspected. Its connection to the job would provide context that an isolated image in a message thread might lack. The owner could review the material when preparing the estimate, even if someone else attended the property.
The business still needs to distinguish an observation from a commitment. A photograph may show the visible condition of a fitting, but it does not establish every material or action needed for the repair. A worker's note can explain what was found. The estimate then expresses the work the business proposes to perform and the amount it intends to charge.
Falconbill's conversational assistant supports preparing estimates and invoices. Depending on the plan, inputs can include text, voice, photos, and WhatsApp. Photo input can help prepare an estimate from a site image. The useful connection is between information captured during the visit and a draft commercial document that the owner can inspect.
For the unit repair, the owner might use the worker's observations to describe the proposed work in ordinary language. If the image left the required part uncertain, the owner would need to settle that question before accepting a draft that named it. The image would support the description; it would not give the assistant authority to decide an unobserved condition or an unagreed scope.
Keeping the evidence close to the job can also make a correction more precise. The owner could identify whether the draft misunderstood the description, used the wrong site, or included work the business had not agreed to quote. Those are different corrections. Merely asking for a better invoice would leave the underlying problem unclear.
Turn conversational input into a document to check
In Falconbill's described voice workflow, the assistant transcribes a spoken description and drafts an invoice using the price book. The user previews and approves the draft before sending. The input is a description of who the work is for and what was done; the output is an invoice whose customer, work description, and line items can be checked.
The price book supplies an existing commercial reference for the draft. A phrase used in conversation has to become an item the business recognizes on an estimate or invoice. That translation can reduce repeated entry, but a familiar-sounding description is not enough to prove that the right item was selected. The owner needs to compare the draft with the intended work and the relevant price-book entry.
In the illustrative job, suppose the owner described the repair together with a diagnostic visit. A useful review would ask whether those were intended as separate charges and whether the draft included each exactly as requested. If the description left that relationship unclear, the owner would need to correct or clarify it.
The amount also deserves its own check. A correct customer and plausible description can coexist with the wrong quantity or line item. The owner would inspect what each line represents and whether the total reflects the intended charge. A rounded amount mentioned in conversation should not silently replace the business's decision about the actual document.
Voice and chat change how the owner enters information. They do not change the meaning of sending an estimate or invoice to a customer. The preview is therefore a practical handoff: the assistant prepares the document, and the user accepts or corrects it before it leaves the business. The customer does not have to become the first reviewer of an incorrectly interpreted request.
WhatsApp provides another described input route, subject to the plan. A message can contain useful job context, but the sender's words still need to refer to the correct customer and work. In the repair example, a short follow-up about the unit could be ambiguous if the owner was handling multiple jobs for that customer. The review would need to preserve the intended job relationship regardless of which conversational channel supplied the input.
Agree the scope before carrying it into an invoice
Falconbill estimates can be shared by email or a public link, and the customer can approve on a phone. An approved estimate can then be converted into an invoice. This carries the quoted information forward and avoids preparing the same commercial document from scratch at the next stage.
For the illustrative unit repair, the owner would review the estimate before sharing it with the property manager. The site and unit would identify where the work belongs. The description would explain the proposed repair, and the line items would show the charge being requested. The customer could then evaluate a concrete proposal instead of trying to infer a price and scope from several messages.
The owner's approval of an AI draft and the customer's approval of an estimate are separate decisions. The first establishes that the business is ready to send its document. The second records the customer's response to the proposed work. Treating a prepared draft as customer-approved would skip the stage that gives the estimate its commercial purpose.
If the work changed after the quote, the owner would need to resolve the difference before treating the earlier estimate as the basis for the final charge. The connection between records helps carry an agreement forward; it cannot decide whether a new item was authorized. In the example, additional work at a different unit would need its own clarification rather than being folded into the original repair because the payer was the same.
Conversion is most useful when the approved scope remains a sound basis for invoicing. The owner can inspect the resulting invoice against that scope and the recorded work. This preserves continuity while leaving the business responsible for the final document. An estimate conversion should not be interpreted as proof that the work was completed or that payment was collected.
Let workers record visits while the owner controls billing
The Crew offering is described as an owner plus four worker seats. Workers have a personal "my visits" view, and the team shares client records and a price book. Billing controls remain owner-only. These roles fit a small crew in which field work can be distributed while the owner retains the commercial decisions.
In the unit-repair example, the assigned worker could attend the visit and add photos. The owner could use the job context when checking the estimate or invoice. The handoff would not require the worker to become the person responsible for the bill. It would also give the owner more context than a message stating only that the visit was finished.
Shared client records are particularly relevant for the property manager with several locations. A worker's assigned visit and the owner's billing review need to refer to the same job. Otherwise, each person could be correct about a different property. The site and unit relationships provide the context for reconciling their views of the work.
Falconbill is aimed at small crews rather than large fleet dispatch. The relevant evaluation is whether the owner and workers can complete this connected sequence with their actual division of responsibilities. A solo operator may perform both sides personally; a crew needs the same context to survive the handoff between people.
Follow the invoice through its payment route
Invoices can be shared through public links. Falconbill describes Stripe Checkout and Stripe Connect for payments into the business's own Stripe account, rather than Falconbill holding the funds. The customer receives a route to pay, while the payment provider handles the payment operation. Available payment methods and account requirements depend on the product and provider setup.
For the completed repair, the owner could share the checked invoice with the property manager. The invoice would state the charge for the identified job. The payment link would give the customer the next action, and the owner could follow the recorded payment status. Preparing the invoice, sending the link, and receiving payment would remain distinct stages of that sequence.
That distinction affects follow-up. If a document is still a draft, the owner has an internal preparation task. If it has been shared and remains unpaid, the next question concerns the customer's payment. A payment recorded by a provider raises different questions from whether money has settled to the business's account. Those states should not be collapsed into a single claim that the job is financially complete.
If the property manager questioned the charge, the connected site, estimate, and invoice would provide a starting point for review. The owner could compare the bill with the approved scope before drafting a response. Any deeper comparison of refunds or settlement timing would require the relevant payment records; it should not infer a failed payment merely because records were updated at different times.
An expanded billing-support assistant could prepare that kind of explanation or finance handoff from approved records. Such exception analysis is a possible extension, separate from the described estimate, invoice, and payment functions. Correcting a charge or making a customer commitment would remain a business decision.
Evaluate the whole job-to-invoice sequence
A useful evaluation would follow an actual job from the initial site record to an invoice the owner accepts and sends. It would record where the owner had to re-enter information, correct the assistant's interpretation, or reconstruct the work from outside the job record. Counting generated drafts alone would miss whether the business could use them.
For a crew, the evaluation would also examine the field-to-owner handoff. Could the owner identify the property and unit, understand the recorded visit, and check the proposed charge without asking the worker to repeat the whole account? That question tests the value of connected records under the division of work the product supports.
Payment timing needs a separate measure. Easier preparation and a usable payment link can remove steps from billing, but they do not establish that customers pay sooner. No measured collections improvement is claimed here. The business would need to follow issued invoices and actual payments over an agreed period to assess that outcome.
The owner could use recurring corrections to choose the next process change. Frequent site corrections would point back to job identification; repeated price-book corrections would call for reviewing the item descriptions and how the work is entered. That review would give the business a specific improvement to test on the next job.