How I Build AI Products Solo: My Experience Building Cruxly and Planio
Two products, zero co-founders. Here's how I decide what to build, where Claude Code actually fits into that, why Planio looks nothing like Cruxly, 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 and PDFs, and Planio, an app for on-site trades like plumbers and electricians. On the surface this looks like split attention. In practice it's a deliberate decision, and in this piece I'm covering the logic behind it: how I decide what to build, where Claude Code actually participates beyond just writing code, and what 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, and what I took away from that might be useful if you're facing the same decision right now: build one thing deeply, or several things in parallel, risking not finishing any of them.
Before going further, it's worth naming upfront what this piece won't be. It won't be a success story with a tidy arc of "it was hard, then it was great." Both products, as of writing this, are still in progress, not at a point where I can sum things up. Some of the decisions I describe here haven't been tested by time yet and could easily turn out to be mistakes I only recognize a year from now. I'd rather write this now, while the decisions are fresh and I still remember why I made them the way I did, than rewrite the story after the fact to fit an already-known outcome.
Worth stating upfront how Cruxly and Planio differ from each other structurally, not just functionally, because that difference shapes literally every decision covered later in this piece. Cruxly is an AI product in the literal sense: it simply doesn't exist without a language model inside it, and the entire value of the product is built around the quality of generation. Planio uses AI only in supporting spots. It's fundamentally a normal B2B app for a specific industry, where the core value is a correctly designed workflow, not text generation. Worth keeping this difference in mind, because I'll keep comparing two products throughout that actually belong to different categories, and conclusions that apply to one don't always carry over to the other without adjustment.
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, backtracking because I'd missed something important.
I didn't immediately realize this was a ready-made product idea. For the first couple of weeks I was just building myself a crutch: a script that pulled subtitles and ran them through a model with a summarization prompt. It worked crudely, mixed up timestamps, and sometimes cut off an important part mid-sentence, but it saved an hour on every video, and that was enough to keep me using it. The moment I decided to turn the crutch into a product came when a friend asked me to "send over that thing you use to take lecture notes," meaning demand showed up before I'd gone looking for it.
The first version of Cruxly solved exactly this one problem and nothing else: feed it a link to a video or PDF, get back a structured summary with timestamps and the option to ask a follow-up question about the content. No marketing site, no social sign-up, just a form and a result. I tested it on myself for two weeks and only after that showed it to ten friends, to see whether it caught someone else's pain, not just my own. Some of the feedback was uncomfortable: two people said the summary was too long and honestly admitted they still wouldn't read the whole thing. Three sentences of substance and a link to the right timestamp would've been enough, and they'd just skim the rest. I almost dismissed this as one person's taste, then got the same comment a third time from someone completely unconnected to the first two and realized it was a pattern, not a coincidence of preference. I redesigned the output format: three lines of substance first, a full summary available on request after that, not the other way around.
Worth admitting directly: the market for AI summarization of video and documents isn't empty. Google's NotebookLM does a similar thing, and does it for free on infrastructure I'll never be able to afford. I didn't pretend that wasn't a problem. Instead I focused on a niche where the big player is overkill: a fast, one-off summary with no need to set up a project, upload a batch of sources, or learn an interface built for a multi-hour research session.
The difference in use case turned out to matter more than the difference in model quality. NotebookLM is great when you already have a folder of sources and you're working with them for weeks, gradually building up context inside one project. I deliberately didn't copy that logic. Instead I built the exact opposite scenario: one link, one request, a result in a minute, with no need to set up an account for a specific project and no interface built for multi-day work where what a person actually needs is a solution to one specific task right now. That's Cruxly. If you're curious about the mechanics of this niche, and why NotebookLM doesn't fully close it off even accounting for Google's scale, I cover that in more detail in the piece on NotebookLM and its alternatives.
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 the way NotebookLM dominates Cruxly's niche, and a handful of mid-sized players like Planado, RO App, and HelloClient, each covering part of the job but not all of it.
Behind that observation is one specific conversation, not an abstract market analysis. 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, and of the three apps he'd tried, each one either cost more than he was willing to pay starting out, or needed more setup than he had free time for between calls. I listened, then asked a few more questions of other friends in similar trades, from plumbers to electricians, and saw 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 request, estimate the cost, plan a route, track the job's status, issue a document to the client. 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. The product's tagline states this directly: bookings, clients, and a schedule for on-site trades in one app.
Before building Planio, I spent time honestly looking at the existing players in this market: Planado, RO App, HelloClient, Lubava, ReMaster. Each one covers part of the same job, and none of them is a blatantly weak product that's easy to beat on raw enthusiasm alone. But each had its own skew: overly complex setup that scares off a solo tradesperson with no technical background in one case, an interface clearly designed for a larger crew rather than one person with one phone in their pocket in another. The task wasn't inventing something fundamentally new, it was pulling together what competitors had scattered across different products or buried behind complicated setup.
The decision to build exactly this, rather than a second AI tool, was strategic, not accidental. I didn't want my entire portfolio depending on one product category that a single model update from OpenAI or Google could undercut. Field-service software is a boring category from a hype standpoint and a sturdy one from a demand standpoint: tradespeople need to take job requests and manage clients regardless of what happens with LLMs this quarter.
Diversification works here the same way it does in any other portfolio: don't put everything in one basket, even a currently fashionable one. I've watched several solo-developer friends build an entire business around a thin wrapper on someone else's API, then watch their product become unnecessary after one release from the underlying model provider. I didn't want to make that mistake a second time, especially since my first product was already sitting squarely in that risky category.
On the technical side, Planio is simpler than Cruxly, and that's a deliberate choice too. There's no dependency on a language model's generation quality here, and so no risk of the product suddenly getting worse because of a change in someone else's API. The main difficulty lives in the details, not the algorithms: a correctly calculated route that accounts for real traffic, a correctly generated document that fits the requirements of a specific type of job, an interface that doesn't confuse a tradesperson opening the app on the run between two jobs, not sitting at a desk. None of these tasks is hard on its own, but they all need to be solved at once, with no room for a visible failure, because a tradesperson the app didn't help in the middle of a busy day is unlikely to open it a second time.
Solo vs. a team: what I lost and what I gained
The decision to run both products alone, rather than find a co-founder or hire a team, is a specific trade-off, not an ideology. I lost speed: where a three-person team parallelizes frontend, backend, and sales, I do everything sequentially, and that physically caps how much can happen in a week. I lost a real-time second opinion. When a decision is contentious, the only person I can discuss it with is myself, and that's reliably worse than arguing it out with someone who has different experience and different blind spots.
A concrete example of that loss: I put off the decision to switch Cruxly's pricing model from one-time payment to a subscription for almost six months, because I wasn't sure and had no one to check my intuition against before spending the time on the rebuild. With a co-founder, that conversation would've taken an hour. Alone, instead of a conversation, I gathered indirect evidence: comparing similar products, reading forums, delaying the decision again, and I ended up making it later than I should have, simply because I was afraid of getting it wrong with no second opinion nearby.
What I got in return is a different kind of decision speed: speed of choosing direction, not speed of execution. No need to align a pivot with a co-founder who spent six months invested in a different hypothesis. No need to explain to an investor why I'm killing a feature I believed in three months ago. Once it became clear that Cruxly's first pricing version was scaring off exactly the users I wanted to retain, I changed it in one evening, because one person makes the call and it doesn't have to go through alignment.
Solo development isn't an ideology, it's a trade-off with a real cost on both sides, and I don't think it's a universally correct choice. For Cruxly and Planio at their current stage, it works, because both products are small enough that one person can physically keep up with the code, the product, and minimal support at once. If either one grows to the point where I can't keep up anymore, that balance will need revisiting, and I'd rather admit that now than be surprised when it happens. I've seen enough stories of a solo founder holding onto sole control past the point where a product genuinely needed a team, and the product suffering for it far more than it would have from the hypothetical loss of control.
Where Claude Code actually fits into this
I wrote in detail about using AI assistants for writing code in the piece on a practical workflow with Claude Code. This entire site, including the text you're reading right now, is written in that pairing. But for Cruxly and Planio, Claude Code isn't just involved in code. It's involved in product decisions: making sense of the database structure before changing it, framing user scenarios before building the interface, finding edge cases in business logic before a live user finds them first.
A concrete example straight from working on this very site. While I was writing this text alongside Claude Code, a real bug surfaced in the CMS: re-saving a post triggered the error published: invalid type: integer 1, expected a boolean. The cause turned out to be mundane: the backend returns the boolean field as an integer from SQLite, and the frontend form sends it back as-is, with no explicit type conversion. It works on the first save, because the value comes from the form already as a boolean, and breaks on the second, because by then the value had cycled through the server's GET response. I wouldn't have noticed this before production if I hadn't stumbled into it while working hands-on. No automated test covered this specific scenario, because I hadn't thought it was even possible.
This is exactly the type of bug that's typical of solo development specifically: no one to look at the code with fresh eyes before a merge, no one to ask "what if this field comes back in the wrong type." Claude Code doesn't replace a human reviewer in a situation like this, but it partly compensates for not having one. I could ask the agent to specifically hunt for similar type mismatches across the entire codebase instead of just fixing the one case and hoping there weren't more. I ran exactly that request right after the fix and found another similar spot in a different form, one that hadn't broken yet but had the same underlying flaw.
Something similar happened earlier with Cyrillic transliteration in a post's slug: two letters, the "hard sign" and "soft sign," letters that modify pronunciation and have no Latin equivalent, were supposed to just disappear when generating a URL, and instead slipped through into the Latin output unprocessed. The cause turned out to be the pattern map[c] || c: the transliteration table deliberately stored an empty string for those two letters, JavaScript treated that empty string as falsy, and the code fell back to the original character instead of the expected empty replacement. The code was formally correct syntax and completely wrong logic, and a mistake like that is hard to catch with a glance at a diff, because the line looks entirely innocent.
In Planio, the same class of problem shows up in business logic rather than code, and it's harder to catch there, because there's no syntax error for a compiler to flag. Example: the cost of a mobile job is tied to distance from the client, and at the design stage I didn't account for the case where a client only has a phone number and no address at all, because the job came in over a call. The formula silently calculated the distance from zero to the tradesperson's coordinates and produced an absurdly small number. I asked the agent to specifically walk through the entire cost-calculation chain and explicitly list which fields are treated as required, which can be missing, and what behavior the code expects for each case of a missing field. That review surfaced two more similar spots I wouldn't have noticed if I'd just fixed the specific address bug and closed the ticket.
The value of Claude Code here isn't that it wrote flawless code on the first try, it didn't, both bugs crept in through ordinary means. The value is in how fast the cause can be tracked down and the whole codebase checked for similar cases once a bug is actually found. That cycle, find it, understand the cause, check the rest of the codebase for the same thing, used to eat an evening. Now it takes half an hour at most, and that's exactly the time I get back for product decisions rather than routine code hunting.
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 player that's bigger, cheaper, and more well-known: NotebookLM. Any pricing strategy has to account for that. Trying to compete on price against a product running on Google's free infrastructure is pointless, I lose that race before it starts. Instead, Cruxly sells speed and simplicity for a one-off use where NotebookLM requires setting up a project and learning an interface built for a long research session.
Cruxly's first pricing version was a mistake, and I'll say so directly. I copied the standard SaaS subscription model because "that's what everyone does," without thinking through whether it fit a one-off use case. Someone who opens the product once a month to summarize one video isn't going to pay for a subscription for that single use, no matter how much value it delivers. I saw this in the conversion from trial use to payment, which stayed stubbornly low even though feedback on the product itself was good. Switching to a one-time payment for a pack of summaries instead of a monthly subscription lifted conversion noticeably, because it finally matched the real usage pattern instead of a model I'd borrowed out of habit from other products.
Planio's situation is different: the niche is fragmented across several mid-sized players, none of which dominates enough that a new product has to explain to users why they'd want an alternative to something already familiar. Here the pricing decision isn't defense against one large competitor, it's a question of exactly where to position among the existing players: pricier with fuller functionality, cheaper and simpler for a solo tradesperson with no employees, or somewhere in between. I chose a free-start entry: a tradesperson sees the value on real job requests before paying for anything, rather than reading marketing copy full of promises.
The difference in approach between these two products shows something I didn't grasp right away at the start: there's no universal pricing formula for "a solo developer's AI product." The formula depends on the structure of the specific niche, a dominant player or a fragmented market, not on the fact that a product was built by one person. I spent more time than I'd like to admit on Cruxly's first mistake precisely because I was looking for one universal recipe instead of asking, from the start, how users actually pay for similar things in this specific niche.
There's another detail I missed at the start with both products: price registers psychologically not just as a number, but as a signal about how serious a product is. Too low a price for Planio read to some tradespeople as "must not have many features," they needed an explanation for why the price was what it was, not just a number with no context. Cruxly has the opposite problem: an audience used to free NotebookLM reacts to any price with "why pay if there's a free option." I had to literally write the answer to that question into the copy next to the price, rather than assume the difference in use case would be obvious on its own.
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 anytime soon. The model that actually works for me: traffic from the blog. Every post on this blog is written as a standalone, useful piece of writing 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 and not a "try it free" call-out in the header.
I tried other channels before settling on this model. Product Hunt brought a spike of visits on launch day and almost nothing after: people browsing sites like that are looking for novelty, not a solution to a specific problem, and most of them never came back even 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 about the product, not try it. Both channels delivered a fast but short-lived spike that left nothing behind still working a month later.
The blog works fundamentally differently. This model is slower than paid ads and more demanding on the quality of the content itself: if a post is written for the sake of the link rather than the reader, both search engines and the reader pick up on that fast, and the link stops delivering anything. But it has a property neither ads nor Product Hunt has: it keeps bringing people in a year after publication, with no additional spend, as long as the post stays relevant and keeps ranking in search.
Cruxly's first 50 users came specifically from a few posts about AI workflows, not from Product Hunt and not from targeted ads: the link to the tool turned out to be the logical next step for someone who'd already been reading about summarizing sources and happened to be looking for exactly this. Planio, because of the product's age, hasn't gone through that same cycle yet in full. The blog as a traffic source for it still needs to be built out, and that's a specific task for the coming months, not an abstract someday intention.
Where a link sits inside a post matters just as much as the fact that it's there at all. A link dropped into the first paragraph simply because that's the easiest place to stick it performs noticeably worse than a link placed exactly where the reader has already formed a specific question in their own mind, and the tool answers precisely that. I keep a strict rule for myself: one article links to the product in at most one or two spots, wherever it fits naturally with the paragraph's meaning, not in every section in a row to maximize clicks. A post that reads like a list of excuses to click the product gets clocked instantly by the reader, and that destroys trust faster than having no links at all.
The metrics I actually track
The temptation for a solo developer is to track vanity metrics: download counts, likes on Twitter, mentions in other people's posts. None of that tells you whether the time you're investing in the product is paying off. I fell for this myself in Cruxly's first few months, refreshing the sign-up counter several times a day and getting excited about every new name on the list, even though most of those people opened the product once and never came back. The metrics I actually check every week now: how many users came back after their first use, how many of those made it to a paid purchase, and how much time I personally spend supporting one active user.
That last metric is the one that gets ignored most often, and the one that's first to kill a solo product. A product can grow in user count while simultaneously eating up more and more of my personal time on support tickets, until it turns out that growing user count actually means growing hours spent on support correspondence rather than development. For Cruxly, that's currently 10 minutes of support per active user per month; for Planio it's higher, because the audience is less technical and more often writes in with questions like "how do I see the route on the map" rather than bug reports.
I deliberately count this metric separately per product, not combined, because a two-product portfolio easily creates the illusion that time gets split evenly. In practice it almost never splits evenly: one week Planio demands attention because of a wave of new questions from tradespeople, the next week Cruxly needs a fix after a new model version release changes the response format. Without a separate counter per product, I wouldn't notice that I've effectively spent three weeks straight on only one of the two while the other one has been sitting completely still.
What I learned about sales as an engineer
I trained as a programmer, not a salesperson, and Cruxly's first few months showed it in every single 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 and doesn't figure things out by trial and error. They either understand the value in the first thirty seconds, or they close the tab.
The first version of Cruxly's home screen opened with a description of the technology: which model was used, how the video-processing pipeline worked, why this was a technically hard problem. To an engineer, a description like that sounds convincing, because it answers the question "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 looking at exactly which screen people most often closed the tab on without ever reaching the link-input form, and seeing it was exactly that first screen with the technical description.
The most useful thing I took away from this: selling isn't a separate stage that happens after a product is done, it's part of the product itself. The wording on the home screen, the order of fields in the request form, what a user sees in the first few seconds after signing up: all of that is selling, even with not a single "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 why any of this mattered differently, until I landed on a version that states the outcome before the technology.
That lesson turned out to apply directly to Planio, even though the audience there is completely different. An on-site tradesperson is even less inclined to poke around an interface than an AI-tool user: they don't have the time, and often don't have the habit, of trying out new software by trial and error between jobs. Planio's first screen had to convey its value in a single glance, not over a full session, and that was harder for me to get right than the equivalent task for Cruxly, because an engineer's intuition serves worse here than the intuition of someone who was once an on-site tradesperson themselves. I compensated by deliberately gathering feedback from several tradespeople on an early version of the interface, showing them the screen with zero explanation from me and watching which button they instinctively tried first, rather than relying on my own sense of what felt convenient.
Solo founding and burnout
Running two products in parallel with no team creates a specific kind of load that's different from ordinary overwork. It's not about the number of hours. It's that accountability never switches over to someone else, not on weekends, not on vacation. If Planio's server goes down at night, I'm the one fixing it, regardless of what's planned for tomorrow.
There was a specific moment when this stopped being an abstract problem and became a real failure. I once spent two days in bed with a fever, unable to open my laptop, and it was exactly during those days that Planio started having trouble generating documents, because of an update to a library that feature depended on. Tradespeople trying to issue a document to a client got an error and had no idea where to turn, because there was no on-call support to speak of. I only found out once I got back to work, from a backlog of emails, and it was an unpleasant lesson: the product had no plan whatsoever for the case where the one person behind it was physically unable to work.
I covered the mechanics of burnout in detail, and what actually helps deal with it, in the piece on preventing burnout. That piece isn't tied to product development specifically, it's about burnout in general, for anyone, not just solo founders. But applied specifically to the "two products, one person" situation, I took away one concrete rule I've enforced strictly since that incident: both products need a way to keep running without my immediate intervention for at least a full day. That doesn't mean hiring someone for on-call coverage, at my scale that's unrealistic. It means monitoring that restarts a crashed process on its own, automated backups with no manual step, and an honest message to users along the lines of "we'll respond within a day" instead of the illusion of round-the-clock support I can't physically provide.
That rule didn't come together right away. The first version of my monitoring just sent me a notification that the server had gone down, which technically works but solves nothing if I can't get out of bed at that moment. I had to separately set up automatic restarts for the failures that usually get fixed by simply restarting the process, and reserve notifications requiring my manual intervention for the rarer, more serious cases. The difference between "notify me" and "fix itself, and only notify me if it couldn't" turned out to be exactly the difference that lets you get sick once without losing the whole product.
What one product teaches the other
I don't run Cruxly and Planio as two isolated universes, even though they're different categories. Some decisions in one product grew directly out of experience gained in the other, and that's one of the few genuine advantages of running two products at once rather than one after another.
From Cruxly to Planio came the discipline of quickly prototyping the interface before building a backend for it. In an AI product this is natural: you first see what format of model output a person can actually understand, and only then build code around that format. I carried the same sequence over into Planio, even though there's no model output there to adapt to. First a paper mockup of the job-request screen, shown to that same friend in the trade, and only after his corrections, an actual database schema built for that screen, rather than the other way around, which is what I would've done by engineer's instinct.
From Planio to Cruxly came something different: patience for slow, unglamorous, but reliable solutions. In the world of AI products it's easy to get swept up in what a newer model or a fancier prompt can make more impressive, and lose sight of basic reliability: what happens if the model's API is unavailable, if the response comes back in an unexpected format, if a user uploads a file the parser can't read. Working on Planio, where a failure means a real tradesperson can't close out a real job for a real client, trained me to take error handling more seriously in Cruxly too, instead of leaving those cases "for later" the way I used to.
Where this goes next
The plan for 2026-2027 for both products comes down to bringing the existing model to a stable state before adding anything new, rather than chasing multiplied growth at any cost. For Cruxly, that means narrower specialization for scenarios where NotebookLM is objectively overkill, rather than trying to catch up to it on breadth of functionality. That race isn't mine to run, and I'm not going to start it just because I could try. If you're curious about the structure of this niche in more detail, I've put together a breakdown of competitors and exactly what can be used to carve out a niche next to a big player in the piece on AI video notes and the piece on AI chat with PDF.
For Planio, the plan is closer to basic than ambitious: get the blog to a point where it actually brings in tradespeople, not just readers interested in AI and productivity. That means writing material for the queries this specific audience actually searches for, rather than reusing the existing blog tangentially, and possibly setting up a separate cluster of articles for this niche if there turns out to be enough material for one. A separate task I'm deliberately putting off for now: figuring out which of the features tradespeople request in support are genuinely needed by many, and which are a one-off case for a single client that shouldn't get turned into a general product feature.
There's also an organizational task not directly tied to either product: rebuilding the "blog drives traffic to the projects" model itself so it scales to a third product, if one shows up, without having to reinvent everything from scratch each time. Right now I have a working setup of tags and contextual links for two clusters, Cruxly and Planio's future cluster, and I can already see which parts of this scheme will need reworking if a third product shows up in a third niche: mainly, the rules that decide which product gets the link from a borderline post that isn't tightly tied to one topic.
None of these plans is guaranteed. I've already 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 exact boolean-field bug in the CMS happened right when I was planning to write this section instead of fixing someone else's code, and I had to push the writing back a day for the fix, because publishing the posts that actually drive readers to both products matters more than the schedule for writing an article about how I build products.
That's probably the most honest thing I can say about what solo-building two products actually looks like: a plan exists, but it only survives until its first collision with reality, and the ability to quickly rebuild it is the only working alternative to not planning at all. I don't expect next quarter to get easier. I expect to get faster at noticing when the plan has drifted from reality, and that's exactly the skill worth writing pieces like this for, even if only for myself and not the reader.
If you're currently deciding whether to build one product deeply or several in parallel, I don't have a ready-made answer for you, because the right choice here depends on things I can't know on your behalf: how much time you genuinely have in a week, whether you're prepared for both products to grow slower than one would, and how ready you are to be the one person accountable for both at 2 AM if something breaks. This decision worked for me at my current scale. Whether it works at the next one, I'll only find out once I get there.
Comments
No comments yet. Be the first.