Built and launched in about two weeks
We built QR.today 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 of a product this size by three U.S. developers over two to three months would cost roughly $87k–130k: 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.
Choose the action the printed code should open
QR.today is a QR creation and campaign product. It supports codes for links, phone numbers, Wi-Fi, email, PDFs, and text, with static and dynamic options and visual customization. Its uses include menus, events, packaging, shared resources, educational material, and portfolios. Each use begins with a specific action someone should be able to take after scanning.
For an organizer sharing a schedule, opening the intended document is the useful result. A restaurant may need the current menu, while an educator may need a resource that students can read on their devices. The visual code is the entry point. Its value depends on the content or action reached after the scan.
A common manual counterpart is to generate a code, insert the image into a design, and treat the task as complete when the artwork is approved. Someone must still check the destination, maintain the shared content, and explain activity afterward. This is a general description of campaign work, not a reported previous process at a particular QR.today customer.
QR.today brings code creation, editable dynamic destinations, hosted PDF replacement, and scan analytics into the product workflow. Those functions address different parts of the campaign. Creation establishes the route; destination maintenance keeps what it reaches useful; analytics describes recorded scanning activity. None of those steps alone establishes that the person completed the intended business action.
The product walkthrough below follows an illustrative event handout linked to a PDF schedule, including the organizer's choices before printing, during a document change, and after the event. QR.today is launched; the additional onboarding, maintenance, and reporting assistants described later remain proposed extensions.
Define the event destination before configuring the code
Suppose an organizer is preparing handouts for next week's event. Attendees should scan a printed code to open the event schedule as a PDF. The organizer would begin by choosing the intended document and identifying the person responsible for its contents. Naming that responsibility early would make it clear who can resolve an outdated schedule before the handout goes to print.
The goal would determine the code type. A PDF would suit a prepared schedule; a link would point to a web destination; an email or phone code would invite a different action. Choosing among them is a content decision before it is a styling decision. An attractive code that opens the wrong kind of action would fail the organizer's purpose even if it scanned consistently.
The organizer would also decide what may need to change after printing. QR.today provides static and dynamic options, and dynamic destinations can be edited after the code is printed. A hosted PDF can be replaced without replacing the printed code. For this schedule, the possibility of a later revision would make continued control of the destination relevant to the choice.
That choice would need to be explicit in the campaign record. The team should not assume that every downloaded code has the same editing or measurement behavior. The selected configuration would determine what the organizer can change through the product later. The public availability of both static and dynamic options does not make them interchangeable for the event's maintenance needs.
A useful working note could name the event, the handout, the destination document, its owner, and the expected next action. This proposed operating record would belong with the campaign preparation. It would let a colleague review the campaign without searching the design file for clues about what the code was meant to do.
Check the destination and the actual printed material
QR.today allows visual customization when creating a code. For the event handout, the organizer could choose the appearance and place the downloaded image into the print design. The next check would need to exercise the code in that final context. A scan of an image on a large screen would not answer whether the code works as placed on the handout.
The organizer would test a representative printed sample on the intended devices and materials. The check would follow the reader's sequence: find the code, scan it, open the destination, and read the schedule. This practical test would identify whether the delivered material supports the expected action without assuming that successful code generation proves the whole sequence works.
A destination review would ask more than whether a page opens. Does the file contain the intended event schedule? Is its revision appropriate for the handout? Can someone read the information needed to choose a session? A technically accessible PDF could still be the wrong document or contain a superseded timetable.
The handout's wording would need to match the destination as well. If the printed instruction promises a schedule, the code should open the schedule or an understandable route to it. Redirecting people to an unrelated general page could leave them searching for the material they were promised. The review would therefore consider the printed invitation and the destination together.
The organizer could record what was checked and what remains unresolved. A successful scan would resolve one question. An unapproved schedule revision would leave a separate content decision open. That distinction would help the person approving print avoid treating a technical test as approval of the event information itself.
If several people contributed to the handout, each would have a concrete review task. The designer would check the final placement, the content owner would confirm the schedule, and the organizer would accept the complete route for attendees.
Replace the schedule while preserving the printed route
Suppose the schedule changed after the handouts were printed. QR.today's dynamic destination editing and hosted PDF replacement make it possible to update what the printed code reaches without replacing the code itself. For the illustrative event, the organizer could use the applicable product workflow to point attendees to the accepted revision.
The replacement decision would begin with the content owner. The organizer would need to know which revised PDF is approved and whether it fulfills the same promise as the original. A new file name or more recent modification date would not by itself establish that a document is ready for attendees. The relevant check is the schedule content and the owner's acceptance of it.
After updating the destination or hosted file, the organizer would scan the existing handout again. That would check the maintained route from the artifact attendees actually hold. Opening the replacement PDF directly would show that the file is readable, but would leave unanswered whether the printed code now reaches it.
This workflow preserves the printed route, not every copy of the information already distributed. Someone who downloaded the previous schedule could still possess that earlier file. If the revision changed an instruction attendees might already be following, the organizer would need to decide how to communicate it through the event's other channels. Updating the destination cannot establish that everyone has seen the change.
The same physical handout may also remain in circulation after the event. The owner would need to decide what a later scan should reach: the final schedule, event resources, or an explanation that the event has ended. Any change should remain understandable in light of the printed wording. Destination control is useful when the organizer continues to own the reader's next step.
A simple maintenance record could preserve which document replaced which and why. That proposed practice would help a colleague distinguish an intentional change from an accidental mismatch. It would also provide context for interpreting scan activity before and after the replacement.
Prepare the reporting question before the event
QR.today provides scan analytics, including device and country information. Those records can support a review of code activity by campaign and period when the available coverage is clear. For the event schedule, the first reporting question could be whether people used the route provided on the handout during the event.
The organizer would define the period and which code the review concerns before reading the total. Preparation scans, activity during the event, and later scans address different operational questions. Where the available records allow a period comparison, the report could describe it. If the available view does not support the desired separation, the limitation would need to remain visible.
The physical placement also affects what the activity can explain. If the same code image appeared on both handouts and posters, a combined count would not automatically distinguish those placements. The team would need a way to distinguish them before claiming that one printed material generated more response. A campaign name alone cannot recover information that was never separated in the measurement.
For this walkthrough, the reporting outline would keep its scope to the schedule route. It could state the code being reviewed, the intended use, the reporting period, the activity available, and any known testing context. That outline would prevent a post-event request for proof of commercial success from silently changing the meaning of the evidence already collected.
Planning the review also clarifies which other records may be needed. If the organizer wants to assess attendance, registrations, or purchases, the corresponding records belong in that investigation. They should be gathered under their own access rules. QR scan data supplies evidence about scanning; it does not by itself supply the missing event or transaction record.
Interpret scan activity at the level it supports
After the event, an activity summary could describe the recorded scans and the available device and country breakdowns. A scan is not the same as a visit, an identified person, or a completed purchase. For the PDF schedule, it also does not establish that the person read the file or followed its instructions. The report should name the recorded activity precisely.
Repeated scanning is one reason a total cannot be read as a headcount. An attendee could return to the schedule more than once, and an organizer could scan while checking the revised file. Without a supported way to distinguish those actions, the summary would retain the total as scan activity. It would not invent a unique-attendee figure from it.
Device information could help the organizer understand which device categories appear in the recorded activity and choose where to focus further usability checks. A large share from one category would not establish that another category had trouble scanning. Diagnosing a device problem would require evidence of the problem, such as a reported failure followed by an appropriate check.
Country information would likewise need to remain a description of the available analytics. It would not establish where an attendee lives, which organization they represent, or whether they attended in person. The organizer would avoid turning a geographic breakdown into an audience profile that the scan record cannot support.
A change in activity after the PDF replacement could prompt a question, but it would not prove that the revision caused the change. The event timetable and distribution of the handout could also affect when people scanned. The useful next step would be to compare the observation with the event context and any relevant records, rather than assign a cause from timing alone.
Proposed assistance for setup, maintenance, and support
An AI-assisted extension could help a customer choose a code type from the action they want people to take. Using current product documentation, it could explain destination updates and measurement options, then prepare a configuration for review. For the event schedule, the useful answer would connect PDF sharing and later replacement with the organizer's need to keep printed handouts usable.
Before print, a proposed readiness assistant could assemble an inventory of approved codes and accessible destinations. It could include campaign names, content owners, and expected next actions, then list missing information and suspected mismatches. The organizer would receive a destination checklist and unresolved issues, with a practical plan for testing the actual printed material. An inaccessible destination would remain an issue to investigate, not proof of why access failed.
The same proposed assistance could support maintenance by flagging broken or outdated destinations within connected campaigns and drafting replacements for approval. It would need access to the relevant campaign information and a basis for judging content freshness. A file that opens successfully may be obsolete, while an old document may still be the accepted reference. The content owner's decision would settle which replacement is appropriate.
After the event, the assistant could prepare a scan summary using the reporting outline and available data. Its review would need to catch unsupported conversions of scans into people or purchases. Recurring setup questions could also become clearer help articles and product feedback, with examples and source links. These are proposed additions to QR.today's described QR and analytics functions.
Destination changes would remain with the campaign owner. A suggested replacement, a drafted help article, and an analytical summary have different acceptance requirements. The organizer could approve the schedule change, the product team could review support guidance, and the campaign reviewer could accept the scan interpretation. Generating those drafts would not itself authorize publishing or changing a live destination.
Evaluate readiness and the quality of the review
A useful assistance pilot would measure setup completion, avoidable configuration errors, preparation time, and corrections required in analytical summaries. For the event handout, the accepted setup would include a usable printed code leading to the intended schedule. A downloaded image alone would leave the destination and print checks unfinished.
Maintenance could be evaluated through the same reader sequence after a revision. Did the existing handout reach the accepted PDF, and could the organizer identify any unresolved content issue? That test would connect the product's editable destination feature with the practical reason for using it. It would not require a claim that every attendee had read the revision.
Reporting quality would depend on whether a reviewer could trace each conclusion to the recorded activity or a separately identified source. Corrections that remove an unsupported attendance claim count as work the reviewer had to perform. Preparation time should therefore be considered together with the effort needed to accept the result. No measured pilot improvement or commercial lift is claimed here.
For a later event, the organizer could use unresolved reporting questions to change the setup before print. If handouts and posters need separate assessment, that distinction should be made when codes are assigned. Both routes could still lead to the intended schedule, while giving the next review a way to tell their activity apart.