Oddig editorial note: Starter Story's headline rounds the earlier revenue to $100 and the later revenue to $10K. The founder describes about $150 monthly before the pivot, about $8.2K MRR plus one-time payments at interview time, and roughly $10K in total monthly sales. Do not collapse those into a $10K MRR claim. The original cover described above remains to be made.
Two years can look like evidence that a product idea is wrong. For Piotr Pobidowski, it was evidence that the way he had packaged the idea was wrong. He built Visualizee, an AI rendering tool for architects and interior designers, while holding a full-time software job. In a Starter Story interview, he says revenue hovered around $100–$150 a month for roughly two years. A major change to the workflow—not a new customer segment or a new market—preceded a rise to approximately $10,000 in combined monthly sales.
The headline needs precision. The founder showed about $8,200 of monthly recurring revenue and said one-time purchases brought total monthly sales close to $10,000. That is more specific than saying the app has “$10K MRR.” Both figures come from the founder in a promotional interview, not audited accounts. The case matters because it points to an error common in technically ambitious products: the tool may be capable of producing what customers want while asking customers to understand too much before they see any result.
Watch 01:33–03:40 for the user task and reported figures, then 05:51–07:53 for the old and new workflows. A transcript is also available through the episode syndication, though the original interview is the primary source.
The paying customer's job was to show a design
An architect may have a sketch, model, or early concept but needs a client to understand how a space could look. Photorealistic visualization can be time-consuming. Visualizee's public site positions the product around generating visualizations from design inputs, and Piotr describes a flow where someone uploads a sketch or model, describes the desired material or style, and receives a render for a client conversation. The customer is not paying for AI nodes. The customer is paying for a presentable artifact and faster iteration around a decision.
The distinction affects product design. A hobbyist may enjoy a node editor because it exposes control. A working designer facing a meeting deadline may care more about producing a convincing alternative quickly. A tool that asks the designer to connect several nodes, set parameters, and write a good prompt before seeing the first useful image makes the user learn the tool's internal logic. A chat-led flow can instead ask a few clarifying questions and produce a candidate render. The underlying model can be similar; the path to value is shorter.
Piotr says his first version took about five months of after-hours work. It had a node-based interface similar to ComfyUI. Customers told him it was too hard to understand. He later simplified the product to a chat-based experience and an AI prompt assistant he calls Vizzi. The assistant helps a user specify the desired result, asks follow-up questions, and sends the request to image-generation services. In the interview, he demonstrates a sketch becoming a realistic-looking home image and a video output. That is a product demonstration, not a controlled assessment of rendering quality across projects.
| User's desired progress | Old workflow friction | New workflow hypothesis |
|---|---|---|
| Start with a sketch or model | Create and connect nodes | Upload the asset directly |
| Express a visual direction | Know parameter and prompt syntax | Answer guided questions or choose materials |
| See a proposal quickly | Configure before generating | Generate a first candidate in fewer steps |
| Revise for a client | Rework technical graph | Refine the conversation and output |
This is why the pivot is more than an interface facelift. It changes who can reach the first successful output. A system may retain advanced controls for expert users, but those controls should not block a new customer's first result. Visualizee's experience suggests a valuable split: simple default path, optional expert depth. The interview does not show measured usability testing before and after, so the extent of each friction reduction remains the founder's account.
What the numbers suggest—and what they cannot isolate
Piotr reports almost three years of product history, two years around $100–$150 a month, and a change about six months before the September 2026 interview. He says the new workflow helped move the business close to $10,000 a month in sales. He also says he changed pricing from one-time payments toward subscription plans. At interview time he described roughly 300 active subscribers, about 300 daily landing-page visits, 5–10 daily new trials, and approximately 25% trial-to-paid conversion. The advertised interview-era plans were a seven-day trial and $35 or $80 monthly subscriptions depending on rendering volume.
Those numbers are coherent enough to take seriously as a lead, but not sufficient to identify a single cause. If 5–10 trials start daily and a quarter pay, that implies about 1.25–2.5 new paid subscriptions per day on average, before cancellations; this is our arithmetic from rounded self-reported figures. Three hundred active subscribers at $35–$80 would imply a broad possible gross recurring range, but plan mix, discounts, timing, and incomplete reporting make the $8.2K MRR figure more useful than multiplying list prices. We should not reverse-engineer a precise conversion funnel from rounded interview numbers.
More importantly, there were at least two contemporaneous changes: the interface was simplified and subscriptions became more prominent. Traffic may also have changed. The interview does not provide a controlled A/B test that isolates interface from monetization or acquisition. The honest conclusion is that the founder associates the rise with the simplified workflow and that behavior reportedly improved—he says people began rendering after signup where earlier they often did not. A builder should investigate activation as the mechanism, while recognizing that the revenue outcome cannot be assigned entirely to one button or chat panel.
The revenue claim does not reveal profit. AI image and video generation can have meaningful variable costs. Users who generate many renders may be much more expensive than occasional users, especially if outputs are retried or upscaled. Hosting, payments, refunds, support, and marketing also matter. An $80 tier might protect gross margin if its limits are calibrated to generation costs; the interview does not provide those costs. Nor does a seven-day trial tell us whether users stay after the first paid month. Sustainable growth would require cohort retention, contribution margin, and repeat client use.
The actual product opportunity: compressing the distance to first value
n
n
Visualizee did not discover a new desire. Architects and designers already need visualizations. The insight was that many of them do not want to operate a generative AI control panel to get one. The founder initially built a system that made sense to a developer: nodes, connections, configurable prompts, and power. His customers needed to upload a reference, describe a room, and show a client a believable visual option. The pivot moved complexity from the user interface into the service.
This is a general product principle but not an excuse to hide important controls. Design work has constraints: dimensions, material fidelity, client preferences, and revision history. A chat system that produces attractive but geometrically wrong images may be fast and unusable. A useful simplification preserves necessary control through a better sequence: first produce a plausible draft, then allow precise edits, then make it easy to compare versions. The real metric is not time to first image; it is time to a client-usable proposal and how often that proposal survives review.
For a rendering tool, the critical path can be tested without an elaborate AI architecture. Give ten target users the same sketch and request a client-ready alternative. Observe whether they know where to upload, whether the assistant asks relevant clarifying questions, how many retries they need, and whether they can explain what changed in the final render. Ask whether they would present it in a real client meeting. Someone saying the image looks impressive is weaker evidence than using it in a work deliverable.
The creator also needs to clarify what the tool is not. A conceptual render is not construction documentation. It should not promise that finishes, dimensions, lighting, or safety specifications match a real build. This is especially important if the outputs look photorealistic. A customer might infer precision from visual polish. Product copy, export labels, and revision tools should set the right expectation.
A diagnostic for a product stuck at low revenue
Before changing the entire market, inspect the user's first session. Where do people abandon? If visitors never start a trial, positioning may be unclear. If trial users upload an image but never generate, the workflow may be confusing or slow. If they generate once but do not return, output usefulness or recurring need may be the issue. If they keep using but do not pay, pricing or value capture may be the issue. Each pattern calls for a different response. Piotr says that after his change, users began rendering more; that is the behavioral link worth checking.
Run a task observation with five new target users, not friends already familiar with the product. Give each a realistic goal and keep quiet while they attempt it. Count steps to first usable output, where they stop, and what they misunderstand. Then simplify the highest-friction step while keeping the underlying value intact. A good experiment changes one major obstacle at a time. If you also change price, homepage copy, traffic source, and onboarding, you may see revenue rise without knowing why.
The next experiment is a controlled pricing test. One-time payments and subscriptions suit different usage patterns. A designer with three intense projects per year may prefer usage credits; a small firm producing renders weekly may prefer a subscription. Forcing every customer into one cadence could raise short-term revenue while increasing churn. Segment by real generation frequency and estimate marginal cost for each group. Piotr says subscriptions helped create recurring revenue, but the interview does not prove they maximize customer satisfaction or lifetime value.
Finally, check whether the “pivot” is truly simpler for the intended person. A chat interface can merely move complexity into a lengthy conversation. If the assistant asks too many questions before generating, the old node friction has returned in another form. The strongest design may use a small number of explicit choices—room type, material, lighting—followed by an editable draft. For some expert architects, a node system might remain valuable. The aim is not to delete capability; it is to stop making mastery a prerequisite for a first outcome.
| Funnel stage | What to measure | What the result could mean |
|---|---|---|
| Visit → trial | Qualified trial-start rate | Demand, positioning, or price clarity |
| Trial → first render | Share creating a first render; time required | Onboarding and workflow friction |
| First render → useful render | Number of revisions; user acceptance | Output quality and controllability |
| Useful render → paid | Payment and refund rates | Captured value versus expectation |
| Paid → repeat month | Active projects and renewal | Whether the job recurs often enough |
These are diagnostic metrics, not promises that changing one number produces a fixed revenue increase. They turn a vague complaint—“marketing isn't working”—into a sequence of falsifiable questions.
A better version of Piotr's lesson
The case is sometimes framed as proof that a simple “AI wrapper” can reach $10,000 per month. That label hides the harder work. Piotr had more than twenty years of software experience, built a niche tool over years, listened to customers who found it difficult, and repositioned the interaction around a work deliverable. The differentiator was not just placing a chat box over an image API. It was understanding why an architect would abandon a technically capable system before producing anything to show a client.
The interview does not verify the reported revenue independently, and its mixed $8.2K MRR/near-$10K total figure should remain explicit. It also does not show retention or margins. Still, the pattern is useful: when a product solves a real job but sales are flat, examine the distance between signup and first successful outcome before rebuilding the whole business. A founder's enthusiasm for technical flexibility is not the same as a customer's willingness to navigate it.
Pivot checklist
- Name the customer's work product, not the technology in the interface.
- Watch new users attempt to produce it without coaching.
- Count abandonment and time to a genuinely usable result.
- Remove or defer the step with the highest friction.
- Keep expert controls available when accuracy requires them.
- Measure activation separately from trial-to-paid and retention.
- Distinguish recurring revenue from one-time sales, and both from profit.
- Check generation cost, refunds, and output reliability before scaling.
Sources & further reading
- Starter Story interview with Piotr, published September 2, 2026 — primary video for the founder's workflow, revenue, pricing, and pivot claims.
- Starter Story episode transcript syndicated by Podscan — timestamped text used to check numerical distinctions; transcription may contain errors.
- Visualizee product website — primary source for current public product positioning, not independent proof of revenue or rendering accuracy.
