DEV Community: Qtim

ChatGPT’s New EU Status Exposes an AI Architecture Problem

Qtim — Mon, 05 Oct 2026 08:34:22 +0000

A product team ships a “search the web” toggle behind a chatbot. The interface barely changes. The system now decides when to browse, rewrites the user’s question, selects sources, and compresses them into one answer. That small toggle creates a much harder audit problem.

On Aug 31, 2026, the European Commission designated ChatGPT a Very Large Online Search Engine under the Digital Services Act. The Commission called it a hybrid service because it answers prompts and can search the web. The classification followed what the product does beneath the interface.

I’m Anton Fokin, CEO of Qtim. We build AI chatbots, RAG systems, and language-model integrations. The useful lesson for product teams is architectural: once a system selects information for users, the final answer stops being enough evidence.

ChatGPT crossed the 45-million-user threshold

ChatGPT reported 159.1 million average monthly users in the EU in the official list, well above the 45 million threshold for a VLOSE. After notification, the service has four months to comply with the additional obligations for the largest search engines. Those include systemic-risk assessment and mitigation, annual independent audits, and data access under defined procedures.

A 2026 Microsoft Research preprint gives the product question more weight. The authors examined 234,839 public ChatGPT conversations collected from 2023 through 2025. They classified 79% of user inputs as difficult to answer through conventional web search. For comparable searchable questions, ChatGPT responses covered less diverse information than Google results across most topics. The dataset is observational and does not represent every user. It still shows that a system can accept a broad question and return a narrower range of information.

The designation imposes obligations on the named services. It does not automatically place every AI product under the DSA. The regulation covers intermediary services offered to recipients in the EU, regardless of the provider’s location. Outside the DSA, public AI products still need traceability when they choose sources for users.

Five checks we use before release

Before an AI feature ships, we ask:

Which information space can the system reach: user input, company documents, partner data, or the open web?
Where does the product select sources and narrow the user’s view?
Can the team reconstruct the path from request to answer across model, instruction, retrieval, and policy versions?
Which users and harms could the feature affect, and what signal would reveal a problem?
Who can inspect the decision a month later, and which evidence will still exist?

The answers define the product boundary more accurately than the word “chatbot.” A closed knowledge base may only need document identifiers and versioning. An open-web product needs a decision log, an evaluation pipeline, and a tested way to stop the feature.

You cannot audit a screenshot

A generative-search answer is the end of at least four decisions: whether to search, which queries to send, which documents and passages to use, and which policies or filters to apply. Two identical answers can come from different sources. Two different answers can come from the same model version after web results or an index changes.

We use a common request identifier to join the evidence chain. It should connect the model and instruction versions, tool calls, generated queries, source or chunk identifiers, policy decisions, the final answer, citations, retries, human intervention, and rollback events.

The tempting shortcut is to keep every prompt, retrieved page, and response forever. That improves reproduction and creates a much larger privacy and security problem. Retention, masking, deletion, and access controls belong in the traceability design. A useful record reconstructs a decision without cloning the conversation database.

Testing also moves one layer down. A fixed “golden answer” breaks as wording changes. More stable checks ask whether the right sources were eligible, the expected tool ran, a policy fired, or a high-risk condition stopped the workflow.

Put risk review in the release path

Article 34 of the DSA requires systemic-risk assessments at least annually and before features likely to have a critical impact on identified risks. Product teams can translate that into a release gate.

Four objects need to stay connected:

the user scenario and the groups it affects;
the risk and the observable signal that would reveal it;
the mitigation, such as a limit, review step, interface change, or policy;
the rollout plan, including monitoring, stop conditions, and rollback.
The DSA does not prescribe a database schema or observability stack. This mapping is our engineering interpretation. Without it, the risk assessment sits in a document, the launch decision in a tracker, and runtime events across several logging systems. An audit becomes a reconstruction project.

A risk record should point to a release version. A metric should point to its definition and dashboard. A launch decision needs an accountable person or role. A feature flag and a tested rollback path carry more weight than a promise to “switch it off quickly.”

Give data access its own boundary

Very large platforms and search engines must provide data necessary for supervision to the Commission or the relevant Digital Services Coordinator after a reasoned request. Vetted researchers use a separate Article 40 process to obtain data for studying systemic risks.

Direct access to production databases creates risks for privacy, trade secrets, and service stability. Ad hoc exports fail more quietly: fields change, metric definitions drift, and two datasets with the same label stop meaning the same thing.

A usable access layer needs versioned schemas, a data dictionary, de-identification rules, access logs, and a reproducible sampling procedure. It also needs a boundary between evidence required for review and information whose disclosure would create another risk.

Scale controls by reach and consequence

Auditability costs time and infrastructure. Risk records, evaluation suites, instruction versioning, richer logs, and controlled exports add work before release. Building the same stack for a small internal assistant wastes time. We scale controls with the breadth of information the system can reach and the consequence of its answer.

User-provided context. Track model and instruction versions, failures, and clear retention boundaries.
A closed knowledge base. Add document identifiers, permissions, citations, retrieval evaluations, and a reliable way to remove outdated material from the index.
The open web and a public audience. Add query traces, source sets, diversity checks, harmful-output scenarios, staged rollout, and rapid rollback.
Large scale or sensitive consequences. Add formal risk assessment, independent-review readiness, reproducible reports, and a controlled data-access layer.

Our rule is simple: once AI selects sources and turns them into one answer, retrieval and generation should be designed as a single auditable decision chain.

We build AI chatbots, RAG systems, and language-model integrations. In an AI product review, we can identify the level of control a use case needs and design it into the architecture before the product scales.

When Loyalty Points Are Deducted Twice: What Breaks Under Load

Qtim — Fri, 02 Oct 2026 11:33:24 +0000

A customer applies points at checkout. The screen hangs, so they tap the button again. A moment later, the balance has changed twice.

For the customer, this is a trust problem. For the retailer, it is a disagreement between the cart, order, payment, loyalty account and marketing report. The discount can look perfectly clear on screen while several systems hold different versions of what happened.

I’m Anton Fokin, CEO of Qtim. This article treats a loyalty program as an operational system: where duplicate deductions come from, why a balance needs an event history, how returns expose missing rules and what teams should decide before the first high-traffic campaign.

The stakes go beyond points. Deloitte’s 2025 Consumer Loyalty Program Survey covered 5,564 adult loyalty-program members in the United States. Among respondents speaking about their favorite brand’s program, 72% said it made them more likely to buy from that brand, while 56% said it led them to spend more. The figures describe a specific U.S. sample and favorite programs, but they show why reliability matters: loyalty mechanics influence both store choice and basket size.

One button crosses the entire order flow

On screen, a loyalty program looks compact: a balance, campaign terms and an “Apply points” button. Behind that button sit the customer profile, promotion rules, cart, order, payment, returns, CRM, analytics and support. Each system updates on its own schedule.

The cart may have reserved the points while the payment service is still processing the charge and the app is displaying a cached balance. Each value can be correct for its own moment and still produce the wrong story for the customer.

Design therefore starts with events. The team needs to define when points are reserved, when a deduction becomes final, which event releases a reservation and what happens after a full or partial cancellation.

One question anchors the model: which system has the authority to make the final change to the loyalty account? Without a clear owner, the website, mobile app, point-of-sale system and CRM can all submit commands for the same purchase.

A retry should return the first result

The most damaging failure often begins with a reasonable recovery attempt. The customer taps “Apply points,” the response is delayed and the app retries. The server may have completed the first operation even though the confirmation never reached the phone.

AWS describes safe retries through idempotent APIs. The client sends a unique request identifier; the service recognizes a duplicate and returns the result of the operation it has already completed. Recording the identifier and changing the data must happen atomically, as a single transaction.

For a loyalty program, the same operation ID should travel through the cart, loyalty service, order and error log. A retry with that ID returns the previous result instead of creating another deduction. If the ID arrives with different parameters, the service should reject it with a traceable error because the customer’s intent has changed.

Accruals need the same protection. A payment service, checkout system or integration may resend an event after a timeout. Without duplicate detection, one purchase can earn points twice, and the problem may surface only during the next order or a campaign-budget reconciliation.

The balance is only the last line of the ledger

“Balance: 2,400” answers one question: how much is available now? Support needs the history behind that number. Which order earned the points? What has already been spent? Which reservation is still active? When did some points expire? Which event corrected an error?

Square’s Loyalty API records each balance change as an event, including point accumulation, reward redemption and expiration. Events remain immutable, while a reversal creates a separate record instead of rewriting the past. That is one vendor’s implementation, but the underlying principle travels well: calculate the current balance from an auditable chain of actions.

An event ledger gives three teams a shared view. Support can explain a specific deduction without comparing several admin panels. Engineers can reproduce the request sequence. Finance and marketing can reconcile program costs with orders, returns and expired rewards.

Corrections should be events too. When an operator simply edits the number in a profile, the reason disappears. A compensating entry preserves the original operation, author, reason and outcome.

Returns expose rules that checkout can hide

Orders and points have different lifecycles. An order can be created, partially paid, split, cancelled or returned item by item. At the same time, its points may be pending, available, reserved for another purchase or expired.

A minimum state map connects those lifecycles:

At checkout, reserve the requested amount.
After the agreed order event, finalize the deduction.
After failed payment or reservation expiry, release the points.
After a return, create a compensating operation according to the program rules.

This is where engineering reaches a business decision. What happens to points earned on a returned item? How should a promotional multiplier be recalculated? What if the customer has already spent the reward? How does a partial return change the account?

The system can execute any rule that has been specified clearly. The owner of the loyalty program has to agree on those answers before development. A transition table makes the agreement testable: initial state, event, next state, permitted retry and action on failure.

Peak traffic needs an explicit failure mode

Campaign traffic rarely spreads evenly across the day. A newsletter, the start of a sale or the final hours before points expire can send thousands of customers to the same operation at once. The service has to validate rules, read the balance, create a reservation and synchronize the result with the order.

The business usually has three degradation strategies:

Block checkout until the loyalty service recovers. This preserves strict consistency and stops sales during the outage.
Complete the order without points and explain the limitation. The team then needs a clear way to honor or compensate the original offer.
Queue the operation and show an intermediate status. This requires a processing deadline and protection against stale commands.

The dangerous option is silent degradation. The interface displays an old balance and lets the customer continue even though another channel has already changed it. The product makes a promise that the operational system cannot keep.

Before a campaign, monitor at least the error rate for accruals and deductions, the delay between an order status and the related loyalty operation, the number of retries, the age of queued messages and discrepancies found during reconciliation. Average service availability can look healthy while the critical purchase path is slowing down.

Different products create the same architectural pressure

In the 4fresh project, Qtim migrated an online store from 1C-Bitrix to a custom solution and developed its loyalty mechanics: an internal currency, referral programs and a premium club. Customer profiles and order history moved at the same time. That connected reward rules directly to customer data and the commercial flow of the store.

In Studycats, six educational courses were brought together on one platform with a shared referral program. The published flow is straightforward: a friend code leads to a purchase, the purchase earns Catcoins, and Catcoins can be exchanged for discounts and promo codes. The same internal currency works across all six courses.

The products are different, but they raise the same questions. Who counts as one user? Which event confirms a purchase? How is a retry recognized? Where does the event history live? What can support see? Once one benefit works across channels and order types, its rules run through the entire product.

The public case studies confirm the product mechanics and scope. They do not disclose the transaction architecture, so the examples should not be read as claims about their internal implementation.

Six questions to answer before a mass campaign

Take one order from campaign eligibility to return and answer six questions:

Event: what triggers an accrual, reservation, deduction, cancellation and compensation?
Source: which system owns the final history of loyalty operations?
Retry: how is one request recognized across all connected services?
State: which intermediate statuses can the customer, support team and analysts see?
Return: how do full and partial cancellations affect earned and spent points?
Failure: what happens to the order when the loyalty service, checkout or integration is unavailable?

Only then is it useful to design screens, APIs, queues, monitoring and test scenarios. An unanswered question will return later as a disagreement between systems.

The load test should include simultaneous deductions from two channels, a retry after timeout, a partial return, cancellation at the reservation-expiry boundary, redelivery of the same event and queue recovery.

If points change the order total, treat them like money

A loyalty program survives peak traffic when every operation can be identified once, moved through explicit states, reconstructed from a ledger and reconciled with the order. Support can explain what happened, marketing can see the true cost of the campaign and the customer sees the balance they were promised.

The decision rule is simple: if points change the order total or create an obligation to the customer, design them with the discipline of a payment operation: unique identifiers, explicit states, an event ledger, reconciliation and monitoring.

If you want to test this flow before a mass campaign, Qtim can trace one order from campaign rules to return and identify where the interface, integrations or architecture need to change. Learn more about our e-commerce platform development work.

Is Your E-Commerce Stack Ready for AI Shopping Agents?

Qtim — Thu, 01 Oct 2026 08:27:28 +0000

Before you expose catalog, inventory, and checkout to an agent, test the six contracts that make one order trustworthy.

“Find me a black jacket with no real fur, deliver it by Saturday, and ask before the final total exceeds my limit.”

The shopper expects a finished order. They do not want eight tabs, three nearly identical products, and a promo code that fails at the last step.

For an AI shopping agent, this is a route: interpret the request, find a product, verify stock, calculate delivery, obtain permission to pay, place the order, and report what happens next. For the retailer, it is a live test of the entire commerce stack. Catalog, ERP or WMS, pricing, checkout, payment, and order management all have to agree.

Hi, I’m Anton Fokin, CEO of Qtim. Here is how we assess whether an e-commerce system is ready for an agentic sales channel, and why choosing the model comes later than getting one order path under control.

Five numbers decide whether the channel is worth keeping

A working API proves that an order can pass through the integration. It says little about whether the channel pays for itself.

We would track five lines during a pilot:

Channel cost. Record the platform fee, payment processing, and any channel-specific service cost for the exact checkout model.
Checkout conversion. Use all orders handed to checkout as the denominator, including failures and abandoned attempts.
Contribution margin. Subtract channel costs, payment fees, returns, and support. More orders can still produce less profit.
Average order value and attachment rate. An agent controls which products and accessories appear together, so compare both order value and the share of baskets with add-on items.
Reachable customer share. Confirm what attribution and contact data the platform passes, and what the retailer may lawfully use in CRM or loyalty programs.

The five lines belong together. A clean transaction log is a technical result. Channel economics depend on the full set.

Attributes become the shelf

A person can open a product page and infer that graphite looks close enough to black. They can notice that size M is gone while size L is available at a nearby store. An agent needs explicit entities: product, purchasable variant, color, size, material, price, location, and fulfillment options.

The UCP catalog specification separates a product from the variant that can actually be bought. Each variant carries its own identifier, price, and availability; checkout refers to that same identifier. This prevents a familiar class of errors: the agent recommends one jacket and adds a namesake in a different size.

Marketing copy and images still shape demand. Inside an agentic flow, however, visibility depends heavily on fields that software can compare. “A deep, refined shade for confident looks” may help a person imagine the item. An agent needs a color code, material, fur policy, available sizes, and delivery constraints.

The practical rule is simple: let the language model interpret intent, then bind the final choice to stable IDs and explicit rules.

Available: true expires at delivery lookup

Inventory is rarely one number. There is physical stock, sellable stock after reservations, display units, returns awaiting inspection, and items sitting in other carts. Delivery adds another condition: the item may exist in one warehouse and still miss Saturday in the shopper’s region.

The agent needs more than available: true. It needs the exact variant, fulfillment area, delivery method, promised window, and the moment when that answer expires.

A catalog response helps the agent find a candidate. Checkout must recalculate availability and return the state the retailer is prepared to honor. Any reservation needs a time to live, a release reason, and a link to the checkout session.

Without that, two agents can buy the last pair of shoes. The warehouse has one box; the software has made two promises.

One price service, or four versions of the truth

The agent sees a catalog price. The shopper then adds an address, selects delivery, applies a promo code, and signs into a loyalty account. Region, tax, shipping, discounts, basket composition, and campaign timing can all change the total.

The stack needs one authoritative pricing service that returns each component and the final amount. Currency should be explicit, and monetary values should use integer minor units so 179.90 never becomes 17,990 through an imaginative reading of amount.

Checkout must return an updated state after every change. When the total crosses the shopper’s approved limit, the agent stops and asks. When inventory disappears, it offers an allowed substitute or cancels the session. Any new total requires fresh confirmation.

Parallel calculators are especially risky. The website uses one discount service, the mobile app uses another, a marketplace receives a nightly export, and the new agent gets a fourth formula. The agentic channel will expose every disagreement. Give it the same pricing source that supports your primary checkout.

Payment authority needs a limit

“Let the agent pay” sounds convenient until the merchant asks who authorized this amount for this seller.

Agentic payment mechanisms replace broad access to card details with scoped authority. Stripe’s Shared Payment Tokens, currently documented as a private-preview capability, can limit a token to a seller, amount, currency, and expiry window without exposing the original credentials.

The merchant must also recognize the agent. Visa’s Trusted Agent Protocol describes signed data that can help a seller verify an approved agent, its relationship to the consumer, and the payment container. This is how the retailer separates an authorized shopping agent from ordinary automated traffic.

We treat autonomous payment as a late-stage capability. First define the seller, category, amount, expiry, substitution rules, and events that return control to the shopper. A first transaction, changed price, high-value order, or non-refundable item may require explicit confirmation. Store the mandate and applied rules with the order so the authorization remains auditable.

A retry must return the first order, not create a second

Agents retry requests. The network drops after payment, the response arrives late, or the client cannot tell whether the order exists. For a programmatic customer, this is normal behavior.

Operations with consequences need idempotency. The agent sends a unique key; a repeated call returns the original result instead of charging the buyer again and creating another order. The current ACP checkout specification requires an idempotency key for creating, updating, completing, and cancelling a checkout session.

We also model checkout as a state machine: collecting information, waiting for input, ready to complete, awaiting confirmation, completed, or cancelled. The server validates transitions. The agent cannot jump from product selection to payment while the address is invalid or the final amount is unconfirmed.

Logs need to connect the user, agent, mandate, checkout session, order, and payment. Then “I approved 180; why was I charged 214?” becomes a traceable event chain instead of a long meeting.

The order survives checkout

A successful payment is the middle of the customer journey. The order may split across warehouses, fail inspection, move to a pickup point, arrive by courier, or enter a return flow. The shopper will ask the same agent, “Where is it?” and later, “How do I return this size?”

The retailer needs an order-lifecycle API with a stable ID, line items, statuses, tracking, documents, and cancellation and return rules. Events can arrive asynchronously, but the current state must always be retrievable. The agent can explain a status in natural language; the source of truth remains the order, warehouse, payment, or carrier system.

Support stays in the merchant’s operating model too. The contract should say what the agent may cancel, when it must ask for confirmation, and when it hands the conversation to a person with the full context attached.

Six backend contracts turn readiness into a test

When we scope a pilot, we walk through one order and test six boundaries:

Catalog. Stable IDs for products and purchasable variants, structured attributes, restrictions, and links to sales policies.
Availability. Checks by variant, location, region, and fulfillment method, plus a fresh validation and time-limited reservation.
Pricing. One calculation for items, discounts, delivery, and tax, with an authoritative total after every change.
Authority and payment. Agent recognition, customer consent, and a scoped payment instrument that never exposes the original credentials.
Order. Idempotent requests, explicit checkout and order states, and an auditable trail for every consequential action.
Aftercare. Status, permitted cancellation or return, and a handoff to a person with the relevant context.

The large language model sits on top of these contracts. It should not become a substitute source for stock, price, permission, or order status.

How We Built a Drone Show Model Marketplace in 2.5 Months

Qtim — Mon, 28 Sep 2026 08:37:07 +0000

A case study in turning a consultation-heavy service into a product journey with 3D previews, protected payments, and source-file delivery.

By Anton Fokin, CEO Qtim

A drone show looks simple from the ground: hundreds of lights move together and form a heart, a logo, or an animated scene in the sky. Buying one is far more involved. Every concept has to be translated into technical parameters — fleet size, spacing between drones, venue dimensions, colors, trajectories, and file formats for the launch team.

DroneShow Gallery set out to shorten that route. The idea was to build a marketplace where a buyer could explore ready-made compositions, see them in motion, check whether they fit the event, pay online, and receive the source files. In 2.5 months, our team at Qtim designed more than 120 screens, built an interface system with over 80 components, and connected a 3D visualizer to the purchase flow.

The first release covered the entire journey from catalog search to protected file delivery. The marketplace had to feel clear to an event buyer and remain useful to the professionals who would adapt and launch the show.

The original purchase journey began with a conversation
Before the marketplace, a client would describe an idea to a drone show operator. The operator collected the venue details, number of drones, colors, and animation requirements, then found a suitable base or created a composition from scratch. A visualization followed, along with revisions and approval.

That process still makes sense for a custom production. The early stages often repeat: hearts, rings, logos, greetings, and other popular concepts are built again and again, even when an existing composition could serve as a starting point.

DroneShow Gallery turned those common requests into a catalog. A customer could choose a scenario before contacting the launch team. The marketplace reduced the discovery work around a standard request while keeping professional adaptation in the process.

One product had to serve two very different users

Event buyers included couples, festival teams, corporate organizers, and other clients. They needed to see the composition, grasp its scale, and judge whether it could work at their venue. Understanding 3D file formats was unnecessary.

Drone show operators approached the same listing differently. A purchased asset was a technical starting point, so they needed specifications and source files they could adapt to the fleet and conditions of a real event.

The interface therefore had to explain each model visually, surface the technical constraints, and make the handoff predictable for both sides.

The MVP covered the complete purchase journey

During pre-project planning, we mapped the first release as a complete path. A user had to be able to:

find models through the catalog, categories, and filters;
save promising options;
open a product page and watch the animation in 3D;
download free preview materials for an early discussion with the launch team;
add one or more assets to the cart and pay through a secure gateway;
receive source files in a personal account;
return to the order history and download purchased fil es again.

Why 48 of 215 design hours went into wireframes

Wireframes took 48 of the project’s 215 design hours. That share was higher than the 5–10% we often see on simpler products, and the reason was scale. More than 120 screens meant that the same states appeared across the catalog, cart, account area, and admin panel. A late change to the underlying logic could spread across dozens of layouts.

We built clickable scenarios and mapped the user flow before polishing typography, color, and visual details. The development team received a stable structure early enough to work on the frontend and server side in parallel.

Design, development, and integrations moved in coordinated sprints. Regular demonstrations gave the client a working result to review throughout the project. That cadence helped the team handle a large interface within the fixed launch window.

The catalog had to respect the shape of each show

Drone show compositions have different proportions. One spreads horizontally, another rises vertically, and a third fits into a square. A rigid card grid would make some models too small or crop away useful details.

We designed a layout that responds to the uploaded material. The system reads the proportions and selects a suitable card treatment, so each composition remains visible and comparable.

Filters use criteria that matter before a launch: number of drones, distance between them, and available venue dimensions. Better matches move higher in the results. Other models stay visible, with a clear warning when the parameters do not align. A professional may still be able to resize the composition or adjust drone placement, so hiding every imperfect match would remove useful options.

A 3D preview turned a file into something a buyer could judge

A static thumbnail cannot show a heart pulsing, individual lights changing intensity, or a full composition shifting in the air. The largest technical integration was the 3D visualizer.

The client uploads model files and supporting materials in the admin panel, adds the specifications, and publishes the asset. The visualizer reads that data and plays the animation on the asset page. A visitor can rotate the scene, change the viewing angle, inspect individual elements, and understand the motion before paying.

Free preview materials add another check. A buyer can share them with the team that will run the show and discuss compatibility before purchasing the source files.

Checkout and file delivery were part of product trust

Digital assets create a specific concern: the buyer wants to know exactly what will arrive after payment, while the marketplace owner needs control over access to the files.

We built the cart, secure checkout, automatic invoices, and transaction confirmation as one connected flow. Blender and OpenUSD files become available only after the payment is confirmed. Temporary download links reduce the risk of uncontrolled sharing, and the user can return to the account later to retrieve a purchased file again.

This familiar e-commerce pattern removed uncertainty from a specialized purchase. The buyer could preview the model, verify the parameters, complete the transaction, and find the files in a predictable place.

The admin panel let the catalog grow without developers

DroneShow Gallery needed to update the library after launch without sending every content change to developers. We integrated an existing admin system and configured it around the marketplace workflow.

The client can upload, edit, and remove models; manage categories and tags; change product cards and prices; control user accounts; and review purchase, visit, and click data. Starting from a ready-made admin foundation saved time in the MVP, while leaving room for new operational tools when real use cases appear.

What stayed outside the first release

The backlog included Google and Apple sign-in, more advanced search, additional filters, search-query analytics, and recommendations for empty result pages. We also discussed an editor that would let users modify models directly on the platform.

The editor was a separate module with its own cost and schedule, so the client chose to revisit it after launch if demand justified the investment. Smaller clarifications entered the active scope when they did not change the overall volume; larger ideas remained visible in the backlog.

This boundary protected the launch date. The first version delivered search, technical checks, 3D playback, checkout, order documents, and protected source files without carrying an untested editor into the release.

The result: a working marketplace in 2.5 months

DroneShow Gallery launched with an asset catalog, technical matching, 3D previews, a cart and payment gateway, automatic invoices, protected source-file delivery, personal accounts, and an admin panel.

The client is now growing the service and collecting usage data. Early feedback suggests that activity is increasing gradually, but the service still needs a longer history before anyone can make confident claims about sales or feature demand.

One possible next step is integrating converters for existing archives. The broader roadmap will follow observed behavior: how buyers search, where filters fall short, whether an editor becomes necessary, and which formats professional teams download most often.

What I value in this project is the way trust comes from small, verifiable steps. I have bought digital assets for projects myself, and the same questions always come up: What exactly will I receive? Where does the payment go? Can I download the file again? DroneShow Gallery answers each one through the purchase flow.

See the complete product flow in the DroneShow Gallery case. If you are planning a marketplace for a complex service or digital product, the Qtim team can help map the first release and build the path from selection to delivery.

What AI costs after launch: tokens, context, storage, and quality control

Qtim — Fri, 11 Sep 2026 09:49:29 +0000

Your AI feature is in production. Users are asking questions, and answers arrive on time. A month later, the product gets a new document: its operating bill.

Token charges are easy to spot. The costs created by long context, knowledge retrieval, storage, engineering tools, and quality checks are easier to miss.

I’m Anton Fokin, CEO Qtim. We build AI chatbots and RAG systems, and our teams use Claude and ChatGPT with Codex. After launch, we separate customer-facing AI costs from the tools used by the delivery team. For the product itself, I track the cost of one useful outcome: an answer backed by the right source, a completed action in another system, or a handoff to a person.

A single model call rarely completes the business task.

The bill starts before the model writes its first word

Model providers charge for tokens, the small units into which text is split. Input and output have separate prices. Cached input has another rate, and Claude also charges for writing a prompt prefix to the cache.

The user’s question is only one part of the input. Before answering, the model may receive a system instruction, tool descriptions, examples, conversation history, and passages from a knowledge base. Output tokens cover what the model generates. The exact numbers should come from the usage field in the API response and be stored for every request.

A practical first formula is:

Cost per response = regular input + cache reads + cache writes + output + tool calls.

Product usage and team tools need separate cost buckets. The table below shows what belongs in each one.

Press enter or click to view image in full size

11,000 input tokens: context multiplies every request

Context is everything the model receives before it answers. In a retrieval-augmented generation (RAG) system, the user’s question becomes a search query. Search returns several passages, and the application adds them to the instruction sent to Claude. The conversation history grows with every message as well.

In the example below, each model call carries 11,000 input tokens. A stable prefix takes 8,000 tokens. The user’s question, chat history, and retrieved documents add another 3,000. The product assembles these pieces separately, but the provider bills them as one input stream.

A large context window shows the model’s technical limit. The invoice depends on the amount of context actually sent. If the application attaches twenty pages of policy text to every request, the provider charges for those pages again as regular or cached input. Extra passages can also make the answer worse by burying the useful paragraph among similar instructions and obsolete versions.

Three controls keep this in check. First, limit the number and size of passages returned by retrieval. Second, summarize older messages into a compact conversation state. Third, cache the stable prefix that contains the system instruction and tool definitions.

With Claude, cache pricing depends on the operation and the entry’s lifetime. A short-lived cache works well when requests arrive close together. With sparse traffic, the prefix will be written again more often. Logs therefore need the actual cache-read rate, while the financial model needs separate rates for cache reads and writes. Anthropic’s prompt caching documentation lists the current multipliers and retention options.

F*ive gigabytes of knowledge: storage, retrieval, and versions are separate costs
Press enter or click to view image in full size
*

A knowledge base has several layers: source files, cleaned text, retrieval chunks, vector representations, an index, request logs, and document versions. Backups and data retained for investigating disputed answers add more storage.

For a 5 GB knowledge base, the budget needs to include vector storage, retrieval operations, backups, and logs. Retrieved passages then enter Claude’s context and are billed again as input tokens.

A self-hosted vector database changes the line-item names but keeps the same cost logic: storage, indexing compute, search, redundancy, and observability. Frequent document changes add re-indexing work. If old versions remain active, retrieval can return a policy that is no longer valid.

Every source needs an owner, a version, and a retention period. After an update, the team should confirm that the new document entered the index, the old one stopped appearing in results, and access rights stayed intact. Otherwise, the company pays to store duplicates and receives answers based on retired rules.

10,000 conversations: an illustrative $811.20 Claude bill

Consider a hypothetical month. This is an illustrative formula based on public rates rather than Qtim project data. The Claude Sonnet 4.6 rates used below were verified on Aug 5, 2026:

10,000 conversations, with four model calls each: 40,000 calls;
8,000 tokens of stable instructions, 3,000 variable input tokens, and 500 output tokens per call;
95% of the stable prefix read from cache and 5% written again.

The model bill is $811.20: $360 for variable input, $91.20 for cache reads, $60 for cache writes, and $300 for output.

Without caching, the same token volume would cost $1,620. The difference is $808.80. The table covers model tokens only; retrieval and storage depend on the infrastructure selected for the product.

The calculation also excludes application servers, databases, queues, monitoring, backups, paid integrations, and specialist time. It does not include taxes, currency conversion, or data-residency premiums. Development costs for the product itself are covered in our separate guide to MVP development costs in 2026. Post-launch operations should be estimated from actual traffic.

Track Codex by completed engineering task
I would not allocate Codex consumption to the cost of a customer conversation. Codex reads code, task history, logs, and command output, then produces changes and explanations. After launch, this cost grows during bug fixes, test updates, incident analysis, and code review.

Codex now uses token-based credit rates for most ChatGPT plans. Input, cached input, and output consume credits at different rates, as shown in the current Codex rate card. For management purposes, I would still calculate credits per completed engineering task, then track context volume, reruns, and automations. That derived metric shows whether a large context and several attempts produced a useful result.

Claude and ChatGPT subscriptions belong in the team’s tooling budget. Keeping them separate from the product API makes changes easier to explain. A higher total can come from more customer traffic, longer Claude responses, or engineering tasks that needed more attempts. One combined number hides the cause.

A wrong answer has its own budget

Forty thousand calls for $811.20 can look inexpensive. The number is only useful while the system cites the current document, respects access rights, and hands difficult cases to a person at the right moment. A bad recommendation can create a support ticket, an invalid order, or legal exposure.

Quality control starts with a test set. It should include routine questions, rare cases, typos, conflicting documents, and attempts to push the system beyond its allowed role. Each example needs an expected source, required answer elements, and a handoff condition.

Run the set again after changes to the prompt, model, retrieval logic, or knowledge base. Add real failures from production logs, and calibrate automated scoring against expert decisions.

This budget line has its own formula:

Quality control = test runs + expert review of a sample + error analysis + fixes.

There is no universal dollar rate for it. One product checks whether an answer cites the correct policy. Another verifies product compatibility. A third confirms whether the user has permission to trigger an action in a CRM. Before launch, define the review frequency, sample size, and person responsible for disputed cases.

Five guardrails keep post-launch costs under control
I would set five limits before users arrive.

Separate budgets for the customer-facing API and the team’s AI tools. This keeps product traffic and engineering work from obscuring each other.
Cost per completed customer outcome and its 95th percentile. An average hides long, expensive conversations.
Context limits. Set caps for history length, retrieved passages, output length, and the share of tokens served from cache.
Routing rules. Send simple requests to a smaller model, complex ones to a stronger model, and high-risk actions to a person.
A quality threshold. Define acceptable rates for answers without sources, incorrect actions, and human handoffs, then alert on cost spikes and quality degradation.

The useful number is the cost of a completed outcome together with the cost of checking it. If you already have an AI workflow and an expected traffic profile, talk to the our team. We can map the full response path across tokens, retrieval, storage, and quality control before the first monthly bill becomes a surprise.

The Button Got Prettier. The Product Is Still Out of Stock

Qtim — Thu, 10 Sep 2026 11:46:49 +0000

Why a redesigned store still loses orders when stock, delivery and order data cannot support the promise on the screen

Hi, I am Anton Fokin, CEO Qtim.

Imagine a product page that says an item is available. In the cart, Friday becomes next Wednesday, the nearest pickup point disappears, and a paid order splits into two shipments without explanation.

The interface can look polished at every step. The customer still leaves with the same impression: the store changed the terms halfway through the purchase.

This is why some redesigns launch cleanly and barely move conversion. They remove visual friction while the order keeps failing in stock data, reservation rules, delivery calculations or status updates. The screen is simply where the customer discovers the failure.

The redesign is live. The order still breaks

DHL’s 2026 eCommerce Trends Report gives the problem a useful scale. In the U.S. findings, 68% of shoppers said they abandon purchases because products are out of stock or unavailable, while 66% leave when delivery options do not meet expectations. Another 40% want real-time inventory updates and back-in-stock alerts.

Customers experience these issues as a series of broken promises. “In stock” turns into “unavailable.” “Arrives Friday” becomes “delivery date to be confirmed.” A pickup option appears, then vanishes. A paid order moves for two days while the status remains unchanged.

A redesign can make the choice clearer and the checkout easier to follow. It cannot create an accurate delivery date or recover a missing order status. Those answers come from the systems and rules behind the storefront.

Five reasons a redesigned store still loses orders

The store offers stock that has already been sold

A retailer may sell through its own site, marketplaces, physical locations and several warehouses at once. When those channels update at different speeds, the product page shows yesterday’s availability. The customer reaches checkout, discovers that the item is gone and learns to distrust the next availability label too.

Track orders cancelled or edited because the stock shown at the moment of choice was wrong. That number is more useful than another round of product-card polishing.

The last unit is promised to two customers

The last item can sit in one cart, wait for payment in another order and remain available on a marketplace. Without clear reservation rules, several customers receive the same promise and only one can complete it.

The store needs clear rules for when an item is held, how long the hold lasts and when it returns to sale. The customer simply needs enough time to finish the purchase.

Delivery gets worse during checkout

A product may arrive tomorrow from one warehouse and next week from another. Cut-off times, parcel size, carrier coverage and split shipments all affect the date. When the store calculates them at the final step, a promising offer turns into an unpleasant surprise.

Show the realistic range early and explain what changes it. A customer can accept a longer wait. A date that moves without explanation feels unreliable.

Pickup and returns become clear too late

Delivery is part of the product decision. Customers want to know where they can collect an order, how long it will be held and how returns work. Revealing those conditions only at checkout forces them to reassess the purchase after investing time in it.

Support cannot explain what happened

After payment, trust depends on clear statuses and useful answers. If support has to check the payment provider, warehouse, carrier and CRM separately, “Where is my order?” becomes an investigation.

Order status, shipment, pickup point, notifications and refund history should form one readable story for the customer and the support team.

Find the broken promise before changing the screen again

When we review an e-commerce product, we follow one order from the product page to delivery and mark every point where the terms change: availability, price, delivery date, pickup option, payment state, shipment and return. Then we compare that journey with the data available to the storefront and support team.

This creates a practical sequence: fix inaccurate stock at the source, rebuild delivery calculations where dates change, clarify correct terms in the interface, and give support a complete order view.

A useful diagnostic rule is simple: when customers leave after the store changes the terms, inspect the underlying data and order flow. When the terms remain stable and people still hesitate, investigate the interface.

Conversion grows when the promise on the screen survives the order. If you want to find where that promise breaks, we can review the customer journey and the systems behind it.

We chose the same Video Tech as Pornhub for an EdTech Platform

Qtim — Tue, 08 Sep 2026 09:07:01 +0000

The reason was practical: paid video has one universal rule. The moment after a click cannot feel broken.

Press enter or click to view image in full size

An online lesson and an 18+ video have one awkward thing in common: when everyone is ready and the video is still loading, patience drains faster than the progress bar moves. In both cases, lag gets in the way.

A student may write, “I can’t get in.” A Pornhub visitor just closes the tab. No screenshots. No “are you definitely in Chrome?” One viewer was there. Then they were gone.

Hi, I am Anton Fokin, CEO of Qtim. This story started with an education platform whose name we keep private. We came in to build a normal way to enter an online lesson, and somehow Pornhub appeared in our work tabs. An odd neighbor for an LMS, and a useful reason to talk about video that has to start without a dramatic pause. It also changed how we look for product references: by user action instead of industry label.

It started with one button: “Join lesson”

The scenario looked harmless. A student opens the schedule, presses “Join lesson,” and lands in class. No link lost in a chat two weeks ago. No small quest called “which account did I use for Zoom?” No message to the teacher asking whether today’s lesson is here or somewhere else.

For video, we chose mediasoup: a foundation that lets the team build entry, roles, and interface around the exact scenario. For the student, the product stayed simple. One button. The machinery behind it stayed out of frame.

That machinery carried most of the work. The “Join lesson” button is really four systems agreeing with each other. Payment goes through, and the lesson opens without an email to an administrator. A teacher reschedules the live class, and the student sees the new time automatically. A recording is ready, and it appears only for the people who have access to that course.

The most difficult part was reconnecting after a failure. Wi-Fi drops, a laptop falls asleep, a child closes the tab. Before, that student had to find the link again and message the teacher. Now the student presses the same button and returns to the same room, in the same role. Boring feature, huge relief.

A ready-made Zoom flow or embedded SDK would have been faster at the start. The cost would have shown up later: the entry point would belong to someone else’s product, with someone else’s screens, accounts, and limits. With mediasoup, the school owns the path. It costs more upfront, but the button leads where the lesson needs it to lead.

The project was moving along until we came across a community discussion about the same technology being used by Pornhub. We checked the name. Then, for research purposes only, someone probably checked their browser history. The coincidence was too useful to leave as an internal joke.

Suddenly, the comparison made uncomfortable sense

Imagine two people in front of a screen. One bought a course and came to class. The other also paid for access, just without a certificate at the end. Both click a button and expect the video to begin. Their tolerance for a loading screen is roughly the same.

For 18+ services, the cost of a pause is visible right away. Chaturbate’s help center describes private shows that bill by the minute and hidden shows that viewers enter after buying a ticket. When a person has paid to watch a stream, a spinner was not part of the evening plan. One extra step or one frozen screen can turn a buyer into a former visitor.

Scale makes the problem sharper. Pornhub’s 2019 Year in Review reported more than 42 billion visits, an average of 115 million per day. At that traffic level, even a small share of tabs closed because a video starts slowly means millions of lost views. A bad video start can show up in a financial report.

In EdTech, the same problem arrives in another package: a disrupted lesson, a support request, an annoyed teacher, and a parent already typing in caps. Revenue may disappear later, along with trust and renewals. The screen lags; the whole school feels it.

The joke from the work chat became a useful reference. Adult platforms test the path to video on people with very short patience. If the screen freezes, nobody writes a thoughtful essay about improving the service. They click away, and the tab becomes history.

That changed how we search for references

Reference hunting often traps teams in a mirror room. Online schools study other online schools. Banks study banks. Delivery apps compare whose courier looks nicer on the map. That helps you check the industry baseline. By the tenth similar product, the whole internet starts to look assembled by one designer.

Now we start by naming the human action. Does someone need to enter paid live content quickly? Look at markets where every delayed second burns money. Does someone need to choose among many options? Look at places where selection has been compressed into one thumb movement. Does the product need people to return every day? Open games, because they have fought for daily habit for years.

How Tinder helped people look for work

In 2014, Jobr borrowed cards and swipes from Tinder. A candidate saw a job, requirements, and matching skills. Swipe right meant interest. Swipe left meant skip. Recruiters reviewed candidate cards in the same motion.

TechCrunch described Jobr as a Tinder-style model for job hunting: quick review for candidates and a faster first filter for recruiters. The interview still happened later. The swipe simply helped both sides reach mutual interest without a long walk through forms.

We saw a smaller version of that pattern in the lesson schedule. A student choosing a lesson time may also face many options, and the decision should take seconds. We checked that screen with the same question Jobr answered: can this choice happen in one motion?

Why Duolingo gave the owl a personality

Duolingo had a different problem: a person studied today, so how do you get them back tomorrow? The answer came from games. Points, leagues, streaks, and the owl’s personality turn the large goal of learning a language into a small reason to come back today.

In one experiment, Duolingo made it easier to keep a streak: one completed lesson was enough, instead of a larger daily goal. Duolingo wrote about the streak experiment and reported a 3.3% relative increase in Day 14 retention and a 1% increase in daily active learners. The mechanic works because the longer a streak lasts, the more annoying it feels to lose it to one lazy evening.

For a school, the return problem sounds different, but it lives in the same place. A course contains dozens of live sessions, and the student has to reach the lesson again and again. That is why we kept the route to class equally short every time. A habit survives when tomorrow feels as easy as yesterday.

By then, our browser tabs looked strange: Jobr took fast choice from dating, Duolingo supported habit with game mechanics, and Pornhub reminded us about the price of a pause before paid video. The rule became simple: look for a familiar action in the industry where that action has already been trained into a reflex.

Back to the online lesson

On the education platform, we connected video with the schedule, user roles, and access to the paid course. A student enters the lesson from the account dashboard, reconnects after a failure, and later sees the recording. The administrator does not create separate rooms or send out links. Support gets fewer reasons to investigate the mysterious sentence, “nothing works for me.”

In this project, we turned the online lesson into one route: entry, access, rescheduling, reconnection, and recording. References from other markets became a stress test. From 18+ platforms, we took the price of the first second: there should be no intermediate screens between click and video. From dating, we took the speed of choice: schedule decisions should not require a half-page form. From games, we took the return rule: tomorrow should be as easy as yesterday.

Inside the school, the result showed up in support. The team stopped sending lesson links one by one, and repeated “I cannot get in” messages became less common. The user has already clicked. From there, the product either takes them where they need to go, or makes them wait, search, and message someone. We built the first path.

If an important scenario in your product has scattered itself across links, chats, and separate services, tell our team about the task. We will map the user path and turn it into one chain, preferably before your audience conducts its own research with the “Close tab” button.

How to Build an MVP in 2026: Scope, Timeline, and Cost

Qtim — Mon, 07 Sep 2026 12:06:14 +0000

A practical guide to deciding when your idea is ready, controlling the first-release scope, and getting to real users in about three months.

By Anton Fokin, CEO of Qtim

How long does it take to build an MVP, and how much does it cost? With a focused scope, about three months is a realistic development timeline. The budget depends on the user journeys, platforms, integrations, release requirements, and technical risks included in the first version.

Those variables become easier to estimate once the team answers a more basic question: what should this release prove?

External pressure often triggers the decision to start. An investor asks for working software. A partner meeting is coming up. A competitor launches something similar. Speed matters in each case, but a rushed prototype can remain a set of screens that produces little evidence about demand.

The opposite happens too. Some teams spend months inside decks, mockups, spreadsheets, meetings, and message threads even though the next answer can only come from real use.

This guide explains when an idea is ready for an MVP, what belongs in the initial version, what affects development cost, and how to structure the work so it can reach users without creating an expensive dead end.

Start with the behavior you need to prove

Before development begins, choose the user action that will count as evidence. “The market needs a service like this” is too broad to measure. A measurable signal is concrete: a user submits a request, pays, completes a lesson, returns a week later, or invites a colleague.

Without a target action, discussions drift toward impressions. Does the screen look clear? Is the form too long? Does the wording feel right? These questions matter later. First, define the event and the metric that will help you assess the outcome.

Broad descriptions make MVPs expensive. “A platform for restaurants” can quickly expand into accounts, roles, notifications, analytics, payments, a mobile app, and a long list of integrations. Narrow the idea to three points:

Who will use the product?
What task will they complete?
Which result will justify further investment?

Interviews, landing pages, and clickable prototypes show how prospective users describe a problem and which promise gets their attention. A live service reveals whether they can reach the intended result on their own.

During a guided demo, most participants follow the expected route. In real use, someone forgets a password, clicks the wrong control, abandons a form, returns three days later, or asks support a question no one predicted. That behavior shows whether the journey works without help from the team.

Qtim used this approach when building Bakki, an onboarding and training app for food-service employees. Course screens alone could not show whether an employee would study during a shift, how a manager would check progress, or where learners would get stuck. The early build therefore had to work as a practical tool from day one.

Scope determines both timeline and cost

Most MVP budgets grow one reasonable feature at a time. A team adds an admin panel, mobile apps, notifications, analytics, new roles, payments, data uploads, and external services. Several tasks marked “later” quietly move into the initial version.

Every item can sound essential in a meeting. In an estimate, each item means design decisions, development, testing, infrastructure, and edge cases. It can also weaken the experiment: after launch, the team struggles to tell whether the result came from the core journey, help from an account manager, a discount, or one of the supporting features.

Define the boundary before implementation. During the first one or two weeks, document the main user journeys, preliminary schedule, budget, technical constraints, and the tasks reserved for the next phase. Remove disputed screens early. A small decision made during scoping can save weeks near launch.

Five variables usually have the largest effect on MVP development cost:

the number of distinct user journeys and roles;
web, iOS, Android, or a combination of platforms;
external services such as payments, maps, identity providers, CRM systems, or partner APIs;
performance, security, offline use, and other release requirements;
uncertainty around the product logic or technical implementation.

A short brief is enough for a rough range. A reliable estimate comes after the team has clarified these variables and agreed on the boundary.

If you already have a product idea, the Qtim MVP team can help define the core journey and prepare a preliminary estimate. The first conversation identifies what belongs in the build now and what can wait.

Build a foundation that can survive the test

Speed should come from a smaller scope and clear decisions. Weak foundations create another kind of cost: authentication, data models, integrations, or deployment processes may need to be rebuilt as soon as the first users arrive.

Even a compact service needs an interface, server-side logic, roles, access rules, external services, a test environment, error monitoring, and a documented release process. Real use exposes missing pieces quickly. The wrong person can see an action, failures can go unnoticed, or every update can depend on one developer.

Connect product analytics before launch. The team needs to see where users reach the intended outcome, where they stop, and which actions they repeat. Useful events might include a return visit, a submitted request, a payment, or an invitation sent to a colleague.

Without that data, the post-launch discussion returns to opinion. The team cannot tell whether to change a screen, the user journey, the offer, or the underlying hypothesis.

Review working software every two weeks

Some teams present a nearly finished build shortly before go-live. Disagreements then appear after much of the budget has been spent, and changes become slower and more expensive.

Short delivery cycles keep decisions close to the work. Every two weeks, the client should be able to open the current build and test it independently. One review may change a button. Another may remove an entire step.

This cadence is especially useful for founders without a technical background. A working build makes progress visible and shows why one feature takes longer than expected. Developers benefit as well because key decisions do not remain scattered across private conversations and individual memories.

The handover also starts before launch. The client should receive the source code, designs, documentation, access credentials, environments, product metrics, and a plan for the next stage. If an internal team will take over later, readable code and usable documentation reduce the time spent reconstructing earlier decisions.

Test demand without development when you can

Some ideas need more evidence before software development starts. A broad audience, a vague target action, or a budget that ends on launch day are good reasons to pause.

Demand can often be tested through interviews, a landing page, a concierge service, or a small pilot. A team can handle the first transactions itself, collect requests in a spreadsheet, match customers with experts, or run a service for several clients. This reveals which operations repeat, where people become confused, and what they will pay for.

Reserve money and time for the first iteration after launch. Early users will expose friction, missing events, weak assumptions, and integration needs. A budget that ends at go-live leaves no room to use what the MVP teaches you.

A practical three-month MVP roadmap

When the hypothesis and target action are clear, a focused MVP can often reach users in about three months. At Qtim, the work usually follows four stages.

Weeks 1–2: product focus
Define the hypothesis, primary users, core journeys, release boundary, preliminary schedule, and budget. Record the features that move to the next iteration.

Weeks 3–5: product foundation
Design the key screens, service architecture, data model, and external integrations. Check whether the chosen approach will support the first customers and the next likely stage of growth.

Weeks 6–14: development and testing
Build the product in short cycles. Share a working version every two weeks so stakeholders can test real journeys, adjust priorities, and resolve questions while changes are still manageable.

Final week: launch and handover
Release the product to users, connect error monitoring and product analytics, and transfer the code and documentation. Confirm who owns production access and who will respond to early issues.

The exact dates depend on scope. A focused release can follow this schedule. Additional platforms, complex roles, unusual integrations, offline behavior, or heavy concurrency need more time and a larger team.

Why a simple product description can hide a large build

The Alps travel platform makes this concrete. It serves passengers, drivers, internal operations, and local partners across resort regions in Austria and Switzerland. Its technical scope included separate applications, an intermediate backend, and a partner administration panel.

Qtim replaced the existing infrastructure through a parallel system so the live service could continue operating during the transition. The project took six months. Offline access also mattered because drivers needed routes and order data in areas with unstable mountain coverage.

This is why the phrase “we need an app” cannot support an estimate. The same label can describe one focused user journey or several connected products with migration, partner operations, offline behavior, and live business constraints.

What should remain after the MVP launches

At the end of an MVP project, the business needs a deployed build, evidence from the main user journeys, a technical base the next team can understand, and a prioritised plan for the next release.

The first useful questions are practical:

Which journeys did users complete?
Where did they stop?
Which actions correlated with real interest?
What needs to change before more users arrive?
Can the current architecture support that change?

Qtim projects have reached this point on different schedules. Bakki launched in eight weeks and later grew from an employee onboarding tool into a broader training system. Konata, a personalised digital business-card service, took four months. Subu, a mobile subscription-management app, took seven months. The timeline reflected the scope and risks of each product.

The same variables determine MVP cost. An estimate becomes useful when the team knows the journeys, platforms, integrations, release requirements, and technical uncertainty involved. Clear boundaries make the budget easier to explain and the result easier to measure.

If you are planning an MVP, contact Qtim to discuss the hypothesis, first-release scope, timeline, and budget. We will review the idea and constraints, then outline a practical route to the first users.