How I Build AI Products Solo: Cruxly and Planio
Two products, zero co-founders. How I price them, find first users with no ad budget, and what failed before any of it started working.
Why two products, not one
I don't have a co-founder, an investor, or a department covering anything while I sleep. There's me, a laptop, and two products I'm building in parallel: Cruxly, an AI tool for summarizing video, PDFs, and documents, and Planio, an app for on-site trades like plumbers and electricians. On the surface, building two unrelated products at once looks like split attention. In practice it's a deliberate decision with a different criterion behind each product. Some of it already failed before any of it started working.
I'm not writing this as advice on "how you too can launch a solo product." I don't have a multimillion-dollar exit and no standing to lecture anyone. What I have is concrete experience launching two different types of product at different times, useful if you're facing the same decision: build one thing deeply, or several things in parallel, risking not finishing any of them.
Both products are still in progress as of writing this, not at a point where I can sum things up. Some decisions here haven't been tested by time yet and could turn out to be mistakes I only recognize a year from now. I'd rather write this while it's fresh than rewrite the story after the fact to fit an already-known outcome.
How Cruxly came to be
The idea for Cruxly grew out of irritation, not market research. I was preparing for a talk at a developer meetup and noticed I was spending more time recapping what I'd already watched or read than engaging with the actual content. An hour-long video turned into thirty minutes of manual work: rewatching, pausing, writing down claims.
It started as a script that pulled subtitles and ran them through a model with a summarization prompt — worked crudely, mixed up timestamps, but saved an hour on every video. The crutch turned into a product when a friend asked me to "send over that thing you use to take lecture notes." Demand showed up before I'd gone looking for it.
The first version solved exactly this one problem: feed it a link to a video or PDF, get back a structured summary with timestamps. No marketing site, just a form and a result. Some early feedback was uncomfortable: several people admitted they still wouldn't read the whole summary — three sentences of substance and a link to the right timestamp would've been enough. I redesigned the output format around that: three lines of substance first, a full summary on request after that.
The market for AI summarization isn't empty, and I'm not pretending otherwise. Major foreign AI tools in this space are largely inaccessible to users in Russia right now, and that's part of the picture too, not just the feature set.
I started with a scenario built for a fast one-off question: one link, one request, a result in a minute, no project setup for a multi-day research session, and that's what my first users grew out of. But today Cruxly's main feature isn't the fast one-off analysis, it's a proper AI Notebook: you add several sources, video, PDF, a web page, and hold one shared chat across them. The fast, no-notebook entry point is still there, just not the center of the product anymore, more a lighter path next to it. That's Cruxly.
How Planio came to be
Planio is the exact opposite of Cruxly in terms of origin. I didn't run into this problem myself: I'm not a plumber or an electrician. The idea came from watching how the market for on-site trade tools is structured in Russia and the CIS: fragmented, with no single dominant player, and a handful of mid-sized players, each covering part of the job but not all of it.
Behind that observation is one specific conversation. A friend who repairs appliances complained that he kept his job list in a paper notebook and kept losing track of who he'd promised to show up for and when. Each of the three apps he'd tried either cost more than he'd pay starting out, or needed more setup than he had time for between calls. A few more friends in similar trades confirmed the same pattern: not a lack of tools, but a lack of a simple way into them.
An on-site trade worker solves the same problem every day: take a job, estimate cost, plan a route, track status, issue a document. Planio handles this in one app: 24/7 online booking, a calendar with a mapped route, job statuses, a client database, cost estimation, auto-generated documents, financial tracking.
Each existing player had its own skew: setup too complex for a tradesperson with no technical background, or an interface clearly built for a crew rather than one person with a phone in their pocket. That fork shaped Planio more than any single screen: I could have built a tool only for a solo tradesperson and hit a ceiling the day he hired his first helper. Instead Planio solves the job equally well for one person and for a ten-person crew, priced by employee count rather than feature set, so the business can grow without switching services.
Building this rather than a second AI tool was strategic: I didn't want the whole portfolio depending on one category a single model update from OpenAI or Google could undercut. Field-service software is boring from a hype standpoint and sturdy from a demand standpoint. I've watched solo-developer friends build a business around a thin wrapper on someone else's API, then watch it become unnecessary after one release from the model provider itself. I didn't want that mistake twice.
Planio is also simpler than Cruxly on the technical side: no dependency on a language model's generation quality, so no risk of the product getting worse from a change in someone else's API. The difficulty lives in the details — a route accounting for real traffic, a document that fits a specific job type, an interface that doesn't confuse a tradesperson on the run between two jobs.
Solo vs. a team: what I lost and what I gained
I run both products alone rather than find a co-founder or hire a team. That's a specific trade-off, not an ideology. I lost speed: where a three-person team parallelizes frontend, backend, and sales, I do everything sequentially. I lost a real-time second opinion, too — a contentious decision can only be discussed with myself.
A concrete example: with a co-founder, the decision on Cruxly's Pro-tier price would've been a single hour-long conversation: discuss it, check intuitions against each other, decide. Alone, there's no one to check intuitions against, so instead of a conversation I had to build the case myself — comparing similar products, reading forums, testing assumptions against real data.
What I got in return is a different kind of speed: choosing direction, not executing on it. No pivot to align with a co-founder invested in a different hypothesis — once it became clear Cruxly's first screen was scaring off the users I wanted to retain, I rewrote it that same evening.
It's a trade-off with a real cost on both sides, not universally correct. For Cruxly and Planio at their current stage it works, because both are small enough that one person can keep up with the code, the product, and minimal support. If either grows past that, the balance will need revisiting.
Pricing and positioning in two different niches
Cruxly and Planio compete in niches with fundamentally different structures, and that directly determines how I sell each of them.
Cruxly has one big free competitor in the AI-notebook space. Trying to compete on price against a free product is pointless. Instead, Cruxly's AI Notebook answers the same use case directly, working across several sources in one shared chat, and keeps a fast, no-signup path for a one-off question alongside it.
Cruxly's pricing is built in three tiers, a direct answer to the question "why pay if there's a free option." Guest access with no sign-up covers a one-off question: one analysis a day, videos up to an hour. A free account lifts some limits and lets you try Second Brain at a volume big enough to feel the difference. The paid Pro tier starts where someone realizes they use the product regularly and is paying for volume and memory, not for access to generation itself. It's a compromise, not a clean solution: the answer to "why pay if there's a free option" had to be built into the free tier, not written next to the price.
Planio's situation is different: the niche is fragmented across several mid-sized players, none dominant enough that a new product has to explain why users need an alternative to something familiar. The pricing decision isn't defense against one large competitor, it's where exactly to position among existing players.
Planio's pricing is built around team size: a solo tradesperson and the owner of a fifty-person company get the same product, the only difference is seats. If pricing differed by feature set, a tradesperson who grew into a crew would have a reason to shop around again. Entry is two weeks free with no card required.
There's no universal pricing formula for "a solo developer's AI product" — it depends on the niche's structure, not on the fact that one person built it. One detail I missed at the start with both: price reads psychologically not just as a number, but as a signal about how serious a product is. Too low a price for Planio read as "must not have many features." Cruxly has the opposite problem: an audience used to free alternatives expects an explanation for why to pay at all. Both are solved the same way — with context next to the price.
First users with no marketing budget
I've never had an ad budget for either product, and I don't plan to set one up. The model that actually works for me: traffic from the blog. Every post is written as a standalone, useful piece for a specific search intent, and only inside it, wherever it fits naturally, is there a contextual link to Cruxly or Planio, not a banner or a "try it free" call-out in the header.
I tried other channels first. Product Hunt brought a spike of visits on launch day and almost nothing after — people browsing sites like that want novelty, not a solution to a specific problem, and most never came back the next day. A post in a relevant subreddit sparked a lively comment discussion and almost zero sign-ups, because that audience showed up to argue, not try the product. Both delivered a fast but short-lived spike that left nothing working a month later.
The blog works differently: slower and more demanding on content quality, but it keeps bringing people in a year after publication, with no additional spend, as long as the post stays relevant and ranks.
Cruxly's first 50 users came from a few posts about AI workflows, not Product Hunt or ads: the link was the logical next step for someone already reading about summarizing sources. Planio, because of its age and the pivot to teams, hasn't gone through that cycle yet in full — the blog as a traffic source for it still needs building out for owners choosing a system for a whole team, not just solo tradespeople.
Where a link sits inside a post matters as much as the fact that it's there. A link in the first paragraph because that's the easiest spot performs worse than one placed where the reader has already formed a specific question the tool answers. I keep a strict rule: one article links to the product in at most one or two spots, wherever it fits the paragraph's meaning. A post that reads like a list of excuses to click the product gets clocked instantly, and that destroys trust faster than no links at all.
The metrics I actually track
The temptation for a solo developer is to track vanity metrics: downloads, likes, mentions in other people's posts. I fell for this myself in Cruxly's first months, refreshing the sign-up counter several times a day — but most of those people opened the product once and never came back.
The metrics I check weekly now: how many users return, how many pay, and how much time I spend supporting one active user. That last one is the most often ignored and the first to kill a solo product: growing user count turns into growing support hours instead of development. For Cruxly that's currently 10 minutes per user a month; for Planio it's higher, since the audience is less technical.
I count this separately per product: a two-product portfolio creates the illusion that time splits evenly, and in practice it almost never does — one product ends up needing more attention than the other, and it's rarely predictable which.
What I learned about sales as an engineer
I trained as a programmer, not a salesperson, and Cruxly's first months showed it in every touchpoint with a potential user. I'd write features and expect them to explain themselves. They don't. Someone opening a product for the first time doesn't read documentation: they either understand the value in the first thirty seconds, or close the tab.
The first version of Cruxly's home screen opened with a description of the technology: which model, how the pipeline worked. To an engineer that sounds convincing, because it answers "how does this work." A user needs an answer to a different question: "what do I get, and why do I need it." I only understood the difference after seeing which screen people most often closed the tab on without reaching the link-input form — exactly the one with the technical description.
The most useful thing I took away: selling isn't a separate stage after a product is done, it's part of the product itself. The wording on the home screen, the order of fields in the form, what a user sees in the first seconds after signing up: all of that is selling, with no "buy" button in sight. I rewrote Cruxly's first screen five times, not because the functionality changed, but because each version of the text explained the point differently.
That lesson applied directly to Planio, with a completely different, now wider, audience. A tradesperson is even less inclined to poke around an interface than an AI-tool user — no time and no habit of trying new software between jobs. A crew owner choosing a system for the whole team looks at the same screen differently: not "will this help me" but "will this hold up for ten people." Planio's first screen has to convince both in one glance. I compensated by gathering feedback from several tradespeople on an early version, showing them the screen with zero explanation and watching which button they tried first.
Solo founding and burnout
Running two products in parallel with no team creates a load different from ordinary overwork: accountability never switches over to someone else, not on weekends, not on vacation.
There was a moment when this stopped being abstract: I once spent two days in bed with a fever, unable to open my laptop, right when Planio started having trouble generating documents because of a library update. Tradespeople got an error and had nowhere to turn — no on-call support existed. The lesson was unpleasant: the product had no plan for the one person behind it being physically unable to work.
I cover the mechanics of burnout, and what actually helps, in the piece on preventing burnout. For "two products, one person" specifically, I took away one rule I've enforced strictly since: both products need a way to keep running without my immediate intervention for at least a day — monitoring that restarts a crashed process on its own, automated backups, and an honest "we'll respond within a day" instead of an illusion of round-the-clock support I can't provide.
What one product teaches the other
Some decisions in one product grew out of experience gained in the other — one of the few genuine advantages of running two at once. From Cruxly to Planio came the discipline of prototyping the interface before the backend. From Planio to Cruxly came patience for slow, reliable solutions: a failure there means a real tradesperson can't close out a real job, and that trained me to take error handling more seriously in Cruxly too.
Where this goes next
The plan for 2026-2027 for both products comes down to bringing the existing model to a stable state, rather than chasing multiplied growth at any cost.
For Cruxly, this is no longer about a feature list. The Notebook, Second Brain, the Chrome extension, transcription, web-page parsing: what was recently a plan is already live. What's next is less flashy but no less important: getting every mode to a point where it doesn't fail. More on the specific tool-choice scenarios in the pieces on AI video notes and AI chat with PDF.
For Planio, the plan ties directly to the pivot to teams: will the owner of a twenty-person company bring their team into Planio as readily as a solo tradesperson creates their first job request. A separate task: get the blog to bring in both tradespeople and owners evaluating the tool for a whole team.
None of this is guaranteed. I've watched a confident quarterly plan fall apart within the first week, twice, because of a bug that ate the time set aside for something else. That's the most honest thing I can say about solo-building two products: a plan exists, but it only survives until its first collision with reality, and rebuilding it quickly is the only working alternative to not planning at all.
If you're deciding whether to build one product deeply or several in parallel, I don't have a ready-made answer — it depends on things I can't know on your behalf: how much time you genuinely have, and how ready you are to be the one person accountable for both at 2 AM if something breaks. This worked for me at my current scale. Whether it works at the next one, I'll find out once I get there.
Comments
No comments yet. Be the first.