The brand

I drew the logo, an “a” made of arcs like a signal, set the name in lowercase and gave it the line “Always connected”. The interface is a dark navy with one blue for actions and red for ending the call. My part was the idea, the brand and the interface; my teammate wrote the code.

The call

Until the other person joins, the screen says so, and a tooltip points to the share button. Then it shows the name, the signal and a timer. On a weak network the bars dim and the line under the name reads “Unstable connection”. The controls sit in one bar at the bottom: camera, flip camera, microphone, share and end. When either microphone is off, a caption says whose. With video, the other person fills the screen and your own picture sits in a corner.

When the call ends, the screen keeps the name and the duration. If a third person opens the same link, the call is already taken, and they can start their own. The same call works on a desktop, with the controls and your own picture along the bottom.

Until the other person joins, nothing else matters.

The waiting screen carries the product

In a product that lives on a link, the first screen most people see is the one where nobody else has arrived yet. If it looks broken, the call never happens. So the waiting screen says what is going on and points at the one thing to do: share the link. Everything I designed after it, the signal bars, the captions, the taken-call screen, only matters once two people are on the call. That is the order I’d design in again: the empty state first, the happy path second.

Who it was for

I made Sequence for designers who, like me, were tired of animating simple screens by hand for Dribbble and portfolio shots. Three screens in a 320×620 window: pick a frame, tune the animation while it plays, then export an MP4 in 720p, 1080p or 4K. Version 1.0 had one preset, Cascade.

The hard part was the file

A Figma layer tree does not map to an animation. Real files have wrapper frames that paint nothing, and cards whose background belongs to the container while the text sits in child layers. Animate each layer on its own and a card’s text flies in while its background stays behind. Most of the work was choosing the right level of the tree to animate.

The analysis walks the layer tree and decides for every node whether it animates, and at which level. A layer covering most of the frame is background and stays still. A large container is opened and its children are analysed one by one, and anything smaller moves as one piece. If an opened container paints something itself, like a card’s fill, that paint becomes a plate and enters together with its content. Groups enter top to bottom, then left to right.

One spec for the preview and the video

The preview and the video read one animation spec: a 16 px rise over 0.4 s per group, 0.16 s between groups and a 0.6 s hold at 30 fps. The plugin plays it with Framer Motion, and the server draws each frame on a canvas and pipes it into ffmpeg, so the MP4 matches the preview. React, TypeScript and Framer Motion in the plugin; Node.js, Fastify, canvas and ffmpeg on the server.

Most of the work in a tool like this is reading the designer’s file correctly.

Why I closed it, and what I think now

When Figma shipped Motion, I read it as the platform doing the same job natively, and I stopped. The render server only ran on my machine, so nobody else ever used it. Looking back, I don’t think Figma Motion would have killed Sequence. I gave up on it. That is the honest post-mortem: the product worked, the file-reading problem was solved, and the decision to stop was mine, made on a headline instead of on users.

Twenty hypotheses, scored

The course started from problems rather than features. People don’t find reliable advice, don’t know what plant they have or what is wrong with it, forget to water, lose interest, and the plants die. Each problem became a hypothesis written as “problem → feature”, twenty in all, from identifying a plant by photo to a forum.

I scored each one from 1 to 5 on six criteria: how much people need it, whether our team could build it, the market, how unique it is, how well it fits current trends, and what it would take. “Plant of the day”, short stories about plants, came out on top with 28. An AI chatbot came second with 25, then watering reminders, a fertilizer picker and a growth diary with 24 each. The marketplace and the forum came last.

Eight interviews

I planned seven interviews, two people aged 30 to 50 and five aged 14 to 30, and ended up talking to eight. The guide had thirteen questions about their plants and how they look after them, three about AI and five about stories and quizzes, because those two ideas had scored highest.

Six of the eight look things up in Google, and a search takes 5 to 15 minutes. “Really inconvenient, slow,” a 17-year-old said. None of them had used a plant care app. Seven wanted help picking fertilizer and pots. Only one trusted AI outright; five would trust it on a condition: an expert checks the advice, it shows photos, or they check it in Google anyway. Only one watched stories in other apps. “No, I don’t notice them,” said the youngest. Quizzes could work if they were short: “A long quiz, too lazy. One question, I’d love it.”

Scoring ideas at a desk put the two that nobody wanted on top.

What changed

The interviews overturned the top of my table: stories and the chatbot were the ones people didn’t want. The chatbot left the MVP. AI stayed only where it shows a result you can check: point the camera at a plant and it names it, with its Latin name, how much light it gets and its condition. Stories went too, after people didn’t notice them in the prototype test either. The same test showed that the button for adding a plant was hard to find, so I fixed it.

Other hypotheses went in as they were: live tips while you aim the camera, the personal catalog as My plants, and the growth diary as a tab on every plant. Everything else waited. On the full product map, the subscription, a family plan, achievements, the chatbot and data export are marked for later. The MVP keeps one path: sign up or skip it, see your plants, open a plant’s card and its diary, or add a plant by photo, check what the camera found and put it in a room.

Eight conversations were enough to overturn the table, and they cost less than designing either feature. I now put them before the scoring, not after, on every project.

LineGuard AI takes drone photos of power lines, finds damaged parts with computer vision and pins them to a route map for an engineer to review. The case came from the Center of Industrial Digital Technologies, which also acted as its client. We built it in three and a half days in a regional round of a Russian national hackathon in 2025 and took first place. I was the designer on a team of three and did all of the design, from the first user flow to the UI kit, the screens, the identity and the pitch deck.

The model will be wrong sometimes

We put four problems in the pitch: manual checks miss small defects; photos differ in light, angle and distance, and parts hide behind others; rare kinds of damage have few examples; and a missed defect or a false alarm can each lead to a failure. The team answered them with augmentation, multi-scale detection, oversampling, a class-weighted loss and confidence calibration. For the interface it meant one thing: the model will be wrong sometimes, so the engineer has to see how sure it is and be able to correct it.

The flow

An engineer drops the drone photos into the upload area, checks them as thumbnails, removes the wrong ones and starts the analysis. While the model works, the screen counts processed files, for example “Processed 6 / 388”.

Each flight is a route with its own page. Four cards at the top give the totals: processed files, detected objects, damages found and objects without damage. The damage card has a red frame and the clean one a green frame, so the number that needs action stands out. Below, the file list shows the status of each photo, sorts damaged files to the top and downloads the whole set as a ZIP. The map places every object using the drone’s image metadata, with its coordinates and the distance along the line.

The review screen

Opening a photo shows the model’s result on top of it: a box around the part and a label such as “Damaged insulator” with its confidence score. Under the photo is every object the model found in the frame, each with its own score. Damage is red, a bird’s nest is orange, and healthy parts stay grey. The engineer can switch between the result and the original photo and outline a missed object by hand.

The totals on the route page only help after the engineer has decided whether to trust a result.

After the hackathon I also laid out the route page for a phone: the cards scroll sideways, with the map and the file list stacked below. The identity is a logo of an eye with a lightning bolt, set in Inter Tight on a dark interface with electric indigo as the accent.

The stack, for the record: YOLO v8 trained in Google Colab on the dataset that came with the case, React with TypeScript, FastAPI, RabbitMQ, PostgreSQL and Docker. The back end and the front end worked by the end of the round.

What I learned applies past power lines. In any tool that hunts for faults, a confidence score on every detection and a way to add what the model missed are what let a person decide whether to trust a result. Design that screen first, and the dashboard after.

The design problem was trust

A chat makes an answer easy to ask for. It still has to help a person decide whether the answer is right. A manager who gets a wrong number with a confident sentence around it is worse off than one who waited for the analyst. There was little time for research, so I looked at how OpenAI, Grok and Gemini design their assistants and borrowed their patterns where they fit.

What the screens do

A manager writes a question the way they would ask a colleague, for example “Show revenue by cohort for January”. The start screen offers topics to begin with and a picker for the data source. The assistant turns the question into SQL, runs it against the database and returns a chart or a table.

When a request is ambiguous, the assistant asks first (“Do you mean the report on product teams?”). While it works, it spells out what it understood: the metric, the filters, the grouping and the sort order. The answer comes with a short explanation, a chart card and a button to turn it into a report. A person can see the interpretation and catch a wrong one before trusting the number.

A clear answer is not the same as a justified one.

I also designed a Tasks screen for questions a team asks on a schedule. A person saves the request once and picks how often it runs, along with the database and the time. Each run keeps its answer and chart, and a task can be run on demand.

Under the hood, and the open question

Basetalk connects to the company’s databases (SQL, Postgres, ClickHouse and others), Git, Jira and Confluence, and answers from them in one conversation. The model was Gemma, running locally, with retrieval over the database schema and safeguards against destructive queries. All of this worked in the prototype; the numbers on the screens are demo data.

The open design question was where the assistant should stop. When it is not sure, the question should go to a human analyst instead of a confident guess. Handing a question to a person deserves as much design as delivering a good answer, and that hand-over is what I would build next.

My part: product and interface design, brand, pitch deck, handoff to developers, and a promo video in After Effects. The prize was about $1,240, converted from roubles at the Central Bank of Russia rate on 28 October 2026.

What the agents built

The nutritionist’s site: React, Vite and Tailwind CSS on the front end, Node.js with Fastify and SQLite on the back end, PostHog for analytics. Atrium: FastAPI, Socket.IO, SQLite and LiveKit on the server; React, HeroUI and Electron on the client, with Claude Code agents doing the building. Sequence: React, TypeScript and Framer Motion in the plugin; Node.js, Fastify, canvas and ffmpeg on the render server. In each, the code is mostly the agents’ and the decisions are mine.

What I decide

On Atrium, the agents built a messenger with glass panels on 15 October and Discord’s layout by 18 October, both in hours. The difference between the two versions is design decisions: what to keep from Discord, what to drop, what to add. The friends wanted chats where chats usually are, and the only original idea that survived was the circles that show who is in which room.

On the nutrition site, the decision was the order: result first, phone number second, and a single path from the problem to a free call. On Sequence, it was which level of the Figma layer tree to animate. None of those came from the agent. An agent will produce whichever version you ask for.

Agents will happily produce another month of features; the scarce skill is deciding, on data, that they shouldn’t.

What I check by hand

Every screen, on a phone and on a desktop. Every event in the analytics: on the nutrition site PostHog records section views, the quiz start and every answer, the result, the contact screen, the messenger choice and whether the form went through, and I read all of them. That is how I found six people pressing Send 21 times with nothing arriving, a bug no screenshot would have shown. Health data gets its own checks: consent before the form sends anything, analytics off until cookies are accepted, encryption in the database, a one-time code on the admin panel.

What cheap building changes

When building gets cheap, stopping gets expensive. Atrium cost a week to build and thirteen interviews, two days, to close. The interviews belonged before the week, not after. Sequence worked end to end, and I closed it on a headline. The nutrition site keeps going because its numbers come from real visitors and I change one thing a month.

So the order I work in now: analytics and interviews first, so the argument comes from users; then the one core flow, built in about two weeks and shipped in a branch your developer reviews; then a test with new users whose sessions you can watch. The agents make the middle part fast. The first and last parts are where the product is decided.

Atrium is a voice and chat app with no centre: each friend group runs its own server and owns its data. I designed it, Claude Code agents built it (FastAPI, Socket.IO, SQLite and LiveKit on the server; React, HeroUI and Electron on the client), and my friends moved onto it. First build on 15 October 2026, public on 17 October with 12 releases in two days, and on 23 October five of us played for three and a half hours on our own server without a problem.

The setup was the product

A central service is one thing to block and one place where everyone’s messages sit, so Atrium has none. Hosting servers myself for $5 a month was the easiest way to grow, and it would have put every group behind my machines, so I gave it up.

The first installer was a terminal wizard, fine for me and a wall for the friend who actually sets the server up. So the setup moved into the desktop app: address, login and password, then the app installs everything, shows each step and ends on an invite link. The password is used once and swapped for a key that can do nothing but update, back up and remove the app. A post on DTF, a large Russian gaming community, got about 4,000 views, and its first comment was about trust: never give anyone access to your server. The key shipped four days later. Trust designed, not explained.

Familiar beat original

On 15 October the app looked like a phone messenger with glass panels. By 18 October it had Discord’s layout. I spent a day on bubbles with physics and a who’s-where canvas instead of chats; the friends wanted chats where chats usually are. Only the circles that show who is in which room survived. People switch because they have to, and every unfamiliar screen is a tax.

The agents built both versions in hours. The difference between them is design decisions: what to keep from Discord, what to drop, what to add.

Thirteen conversations, no demand

With my friends on the server, I went looking for who else needed one. Two days, thirteen people who call friends to play or talk, one question that worked: when did a call last break for you, and what did you do? Nine live in Russia. Those who wanted Discord had it working; the rest used whatever was already on their phone. One person named a problem: about once a month a friend drops out and the group moves to a free TeamSpeak server for the evening. Free backups closed every pain I heard.

Two segments showed up that I hadn’t built for: a tutor whose students need to join lessons without installing anything, and the host of a private gaming community in Turkey, 15 to 20 members, most of them in Russia. Both need a different product.

When building gets cheap, stopping gets expensive.

Why I stopped

The goal was ten strangers coming back to a voice room twice in a week by 25 November. After thirteen conversations the count was zero. My pain was real, and it was mine: the circle I built for had solved it for free, and the people who hadn’t were not the people I knew. Building cost a week. Another month would have cost a month and taught me the same thing. The code stays open on GitHub, and my friends keep their server.

Three things I’d do again, in a different order. My own pain is a hypothesis with a sample of one. Thirteen conversations cost two days, less than any feature, and they belonged before the week of building, not after. And ask about the last time something broke, not whether people like the idea. Liking is free. Switching costs an evening.

The brief

A new workspace had no onboarding. A new user landed on a sidebar of thirteen sections, from Omni Hub and Staff to Variables, MCPs, Flows and Logs, and had to work out alone where an agent comes from. Alloy had no data on where people gave up, but the product has a lot of features and the interface didn’t help.

The CPO had a guided tour in mind: a cursor that moves and clicks on its own to show where things are, then asks the user to click. I went another way. Alloy is an AI product through and through, an operating system for AI agents, so the onboarding should be AI too: a conversation with Ally, the assistant every workspace already has.

The hypothesis

If Ally runs the setup as a chat, a new user gets to a first working agent sooner than through settings pages, and Ally learns about the business on the way. Before drawing anything, I signed up to Alloy and went through the onboarding of other products. Notion’s worked best: its AI offers to set up the workspace in a chat, and I took apart why that works.

What the conversation asks

The onboarding runs inside the normal Alloy interface, so the sidebar is there from the first minute. Ally opens with one question, what to build first, and two answers: an agent for the company’s website, or agents for internal operations.

Two short questions follow, what the company does and the user’s role, each with ready answers as chips. Every reply from Ally carries a collapsed “Thought for 15 seconds” line, as in Alloy’s own chat. Then Ally asks about the business and says it will use the answer to train the assistant. The user can drop files, paste the website address, type a few lines, or skip with “I’ll share it later”.

Next Ally asks which routine the agent should take on, with three presets (lead qualification, FAQ and support, product navigation and upsell) or a task in the user’s own words, and asks for a name. The last message says the agent is live and gives a script to paste on the website, with a link to the webchat settings for colors, avatar and trigger rules.

Skipping the files doesn’t block the launch. The agent still goes live, but Ally warns that its memory is empty and points to Storage, where the files can be added later. A “Complete your workspace” card in the sidebar keeps the rest of the setup in view as a short checklist with progress: create the first agent, feed the system with company data, connect an external source, invite the team.

The first screen asks one question and ends with a working agent.

What held up, and what didn’t

The CEO and the CPO liked the onboarding, and the deck went down well. The restyle of the Staff page and Ally’s panel, built on HeroUI and shadcn, got taken apart on UX. They asked why I left so much empty space, since their rule is to use every bit of the screen, and I had no argument ready. The onboarding held up because I could show how Notion does it and why it works. The restyle didn’t, because it rested on my taste.

Soon after, Alloy shifted its effort from improving the product to rolling it out to customers, and the work ended there. As far as I know, none of it reached the product, so there are no numbers.

What I took from it: don’t copy another product’s pattern without knowing why it works there. Find out who will look at the work before choosing how it looks; my first deck was red, and they said it looked as if someone had been killed, and AI companies sell transparency and trust, so it became white and blue. Stakeholders read UX and business logic before beauty. And back every decision. Now every project starts with analytics and user interviews, so the argument comes from users, not from me.

One path

The landing page has one path: the problem, the quiz, the result, a free call. Testimonials are real Telegram conversations, and visitors can open the channel and check them. Three prices lead into each other: a diagnostic session for about $50, a consultation with a plan for about $185, and three months of coaching for about $805. Most of the selling happens on the free 15-minute call, where Nadezhda looks at the situation and recommends one of them. Both first sales were decided on that call.

The quiz asks ten questions about how a person feels: mornings, energy through the day, coffee, digestion, cravings for sweets, sleep, the days before a period, hair and skin, weight and stress. Each answer adds weight to one or more of five areas: blood sugar and energy, sleep and recovery, digestion, hormonal balance, and deficiencies of iron, vitamin D and B12. The result names the area that scored highest in plain words, lists what to change right away, and only then asks for a phone number.

Every lead arrives in a small admin panel with the quiz answers, sorted by area. Nadezhda adds notes and sets a status: new, contacted or closed. PostHog records every step: section views, the quiz start and every answer, the result, the contact screen, the messenger choice and whether the form went through.

The first signal was false

At launch most visitors were friends and family testing the site. They clicked around, finished the quiz, looked at the result and left without a phone number. I assumed the order was wrong and that the quiz should ask for contacts before showing the result. Splitting traffic by source changed that: 70 direct visits from people I had sent the link to produced no leads, and every lead came from Instagram.

Filter out your own traffic before you trust any number.

The second finding was worse. I had launched with a third-party form service so I wouldn’t build a back end before there was demand. In August the analytics showed people choosing a messenger, typing their number, pressing Send and getting an error. Six people tried 21 times in total, and none of the requests arrived. I built my own back end, and since 26 August every request has arrived.

The third came from heatmaps: visitors read the pricing section and left, most likely unsure which tier fit them. I added a line under the tiers: “Not sure which one you need? Take the quiz or message me.” One of the first two paying clients came through that button.

Where people drop off now

From 26 August to 25 September, 82 people visited, 22 started the quiz, 18 finished it, 14 saw the contact screen, 8 sent their contacts and 2 paid. The contact screen is the next experiment: four in ten people who reach it leave without sending. Only 14 people a month get that far, too few to call a test in one month, so I’m waiting for more traffic before changing it.

Health data

The quiz asks about sleep, digestion and periods, which makes the answers health data. The form sends nothing until the person agrees to the processing of their personal data. Analytics stays off until the visitor accepts cookies. Names, phone numbers, quiz answers and notes are encrypted in the database, and the admin panel asks for a password and a one-time code. None of this is visible on the page, and all of it is part of why a practice can put its name on it.

PostHog counts only visitors who accepted cookies, and my own visits are filtered out, so real traffic is higher. Payments are recorded by the practice. Dollar amounts are converted from roubles at the Central Bank of Russia rate on 28 October 2026.

What I’d tell another practice: a cheap entry offer and a free short call sell the long programs better than the page does on its own. Build less before demand is proven, but watch closely what breaks.

I have now watched that path fall apart in five products I worked on, and it fell apart in the same few places each time. Here they are, with what I did about them, and then the two weeks I spend finding the sixth.

A setup that needs an engineer

Atrium is a voice and chat app where each friend group runs its own server. The first installer was a terminal wizard. It was fine for me and a wall for the friend who actually sets the server up. So the setup moved into the desktop app: address, login and password, then the app installs everything, shows each step and ends on an invite link. The friends installed it without hints; their only question was which server address to type. The product did not change. The first ten minutes did.

A sidebar with no first step

A new Alloy workspace had no onboarding. A new user landed on a sidebar of thirteen sections, from Omni Hub and Staff to Variables, MCPs, Flows and Logs, and had to work out alone where an agent comes from. Alloy had no data on where people gave up. The product has a lot of features, and the interface didn’t say which one to touch first. I made the setup a conversation with Ally, the assistant every workspace already has: what to build first, a few questions about the business, and a last message that says the agent is live, with the code to paste on the website. The CEO and the CPO liked it. The point is not the chat. The point is that the first screen now asks one question and ends with a working agent.

A form that breaks in silence

On the nutritionist’s site the quiz worked, the result worked, and the contact form was losing every lead. I had launched with a third-party form service so I wouldn’t build a back end before there was demand. In August the analytics showed people choosing a messenger, typing their number, pressing Send and getting an error. Six people tried 21 times, and none of the requests arrived. Nobody complained; they just left. I built my own back end, and since 26 August every request has arrived. A broken step near the aha moment doesn’t look like a design problem on a screenshot. It only shows in the events.

The failing form was the clearest demand signal I got.

An answer nobody can check

Basetalk turns a manager’s question into SQL and returns a chart. A chat makes an answer easy to ask for; it still has to help a person decide whether the answer is right. So while it works, the assistant spells out what it understood: the metric, the filters, the grouping and the sort order, and it asks first when a request is ambiguous. LineGuard, which finds damaged parts in drone photos of power lines, shows a confidence score on every detection and lets the engineer outline what the model missed. In both, the aha moment is not the answer. It is the moment the person trusts the answer enough to act on it.

A feature nobody asked for

Plantify’s chatbot had scored second of twenty ideas at my desk. Eight interviews later it left the MVP: only one of eight people trusted AI advice outright, and five would trust it only on a condition they could check. AI stayed where its result can be checked, a camera that names the plant in front of you. A first task that people don’t want is not a first task.

How I find it in two weeks

Week one: an analytics event on every step to payment, so we see where new users drop, and 8 user interviews, which I run, so we hear why. Week two: the path to the first task, shipped in a branch of your code that your developer reviews, a keep-or-cut list for your features, and a test with 5 new users, their sessions recorded in PostHog for you to watch.

The goal is written down at kickoff, so we both know what counts: 5 new users reach their first task without help. If they don’t, I keep working for up to 2 more weeks for free. That is the Aha Sprint, and the cases above are why it is built the way it is.

Many practice sites get far less traffic than a split test needs. At that volume a test can run for months before the difference means anything, and the whole time half of your visitors see the weaker version.

What I do instead

On small traffic I change one thing a month and compare the month before with the month after. This is weaker evidence, and I treat it as weaker evidence. A holiday or a post that did well on Instagram moves the numbers too, so I write down what else happened that month next to the result. A rise after a holiday then doesn’t get credited to a new headline.

One change at a time is what keeps this comparison honest.

If I rewrite the first screen and shorten the quiz in the same month and bookings go up, neither of us knows which change did it, and the next month starts from a guess.

Where a change goes

Each experiment starts from something I saw in the analytics or in session recordings: a question where people quit the quiz, or a screen where they scroll up and down without clicking. The change goes at that spot. The report names the change and the reason for it, then gives the booking numbers and anything else that happened that month.

Some months nothing moves. That goes in the report as it is, and the next experiment tries a different spot. Month by month you get a page where each part has been checked against real visitors, with a written record of why each part is there.

For a healthtech team with enough traffic, the same work runs as proper split tests in PostHog. One question per test still holds.

Why this order

I ordered it this way on purpose. Someone who has just answered ten personal questions has already given a lot. If the next screen asks for a phone number before showing anything, the quiz starts to feel like a trap. Some people close the tab. Others type a fake number to get past the form, and the specialist gets a lead she can’t call.

With the result first, the visitor leaves with something useful whether they write or not.

The people who do leave a number have just read a description of their problem, and they want to talk about it. Their answers and the result arrive with the contact, so the specialist knows what they said before her first message.

Two smaller details follow the same idea. The quiz asks for a name only to use it on the result screen, and the visitor can skip that step. The contact form lets them pick the messenger they already use, so the reply arrives where they will see it.

What it costs

Some visitors read the result and leave, and a gated quiz would have caught their numbers. For a practice where every call takes time out of the specialist’s day, I think that is the right trade.

The order also makes the analytics easier to read. The result screen and the contact screen are separate steps, so I can see how many people reached a result and how many of them chose to leave a contact. If that share falls after a change, the cause is on one of two screens, and I know where to look.

For a healthtech product the same order works with a different reward. Show the recommendation or the plan first, then ask for the email.

The top line is booked consultations. A practice earns money when someone who fits books a call and then pays for the program. The step numbers are there to explain why bookings moved, or why they stayed put.

Step numbers are easy to push up.

Cut the quiz in half and more people finish it. Ask for the phone number before showing the result and you collect more numbers. Both changes look good on a chart. The specialist then spends her week on calls with people who were never going to buy.

How a change is judged

Every experiment starts from a guess about bookings. Say visitors stop at the phone step because they don’t know what happens after they leave a number. The change is one sentence under the form that says who will write back and in which messenger. The step numbers show whether more people got through the form. Bookings show whether it mattered.

For a small practice, bookings are a small number, and they move slowly. The report says so plainly. A good month is a reason to keep watching, and I call it a result only after it holds for another month.

What counts as a booking

For a healthtech team the rule is the same with a different name. The top line is qualified leads: people who match the product and leave a way to reach them. Sign-ups from outside your market are cheap to get, and each one costs someone on the team time.

Before any design work, we agree on what counts as a booking or a qualified lead in your business. That definition goes into the analytics first, and every report is measured against it.