DEV Community: Qtim

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.