Velin

The Situation

I am a solo creative working across two distinct audiences at once: clients who hire me for work, and a wider audience that follows the artistry. Running both means running two separate kinds of relationships, two separate kinds of communication, and two separate sets of expectations. For a long time, that also meant two separate stacks of platforms, none of which talked to each other cleanly. Velin is my attempt to collapse all of that into one place, built to my own spec from the ground up.

What Was in the Way

The core problem was not that the platforms I was using were bad. The problem was that none of them were built for someone doing both things at once. A client management tool does not care about an audience. A creator platform does not care about project pipelines. So I was paying for multiple subscriptions, logging into multiple dashboards, and manually moving information between them whenever the two sides of my work overlapped, which they do constantly.

The cost was time, but it was also friction in the experience I was giving people. A client trying to reach me might land in one place while a follower landed somewhere else entirely, and neither experience was the one I actually wanted to offer. I had workarounds for most of the gaps, but workarounds do not scale and they do not look like a practitioner who has their process together.

Beyond the operational cost, there was a design cost. The platforms I was using made decisions for me, about layout, about workflow, about what the user sees and in what order. Those decisions were not wrong for the average user. They were wrong for me. I wanted a platform that ran the way I think, not the way someone else’s product team decided was good enough for most people.

The gap between what existed and what I needed was wide enough that building something from scratch was the more rational choice, not the extravagant one.

What I Did

I designed the product in Figma first, working through the structure of how the two audiences would move through the same platform without colliding with each other. The client-facing side and the artistry-facing side needed to coexist without either feeling like an afterthought bolted onto the other one’s home.

For development, I used Claude Code. This is worth being direct about, because there is a common assumption that using AI for development means typing a prompt and publishing whatever comes back. That is not how it worked here, and that is not how development works at all, with or without AI. I would give a specific instruction, review what came back, find where it was close but not right, revise, and go again. The loop was long and it was repeated hundreds of times across three months of active work. The decisions about what the product should do and how it should behave were mine. The AI handled the code that would have otherwise taken me years to write by hand, because I am not a career developer and learning a coding language from scratch to this level of complexity was not the right trade of time.

What I fought hardest for was the user experience detail. It would have been easy to call something done once it was functional. Functional and right are not the same thing. I spent a disproportionate amount of development time on the parts a user never consciously notices: the flow between screens, the logic of what happens next, the places where a platform can quietly frustrate someone without ever throwing an error. Those are the parts I kept returning to because those are the parts that determine whether someone stays or leaves.

The product is not finished as of this writing. That is a constraint I accepted going in. Building something this specific takes the time it takes.

What Happened

Velin is still in active development at the three-month mark. There is no completed outcome to report yet, no usage numbers, no revenue. What exists is a platform that is far enough along to be useful and specific enough that it could not have come from a template or an existing tool.

The intended outcome is straightforward: once it is complete, I use it myself. Client work through one door, audience through another, and me managing both from a single place without the platform making choices I did not ask for. If the product works as well for me as I believe it will, and if the experience holds up for others the way it holds up for me, the longer-term intent is to sell access to other solo creatives who are running the same two-track operation I was running before I built this.

That is a future state. Right now the measure of progress is whether the product does what I designed it to do, and the answer to that is getting closer to yes with every revision cycle.

What I Took From It

The clearest thing I am carrying forward is that using AI for development does not remove judgment, it relocates it. The judgment is not in the code anymore. It is in every instruction given to the AI, every review of what comes back, and every decision about whether close enough is actually good enough. That is still a design skill and a product thinking skill. The tool changed. The thinking did not.

I also learned that building for yourself is genuinely harder than building for a client, because there is no external brief to push against. Every decision about scope and priority lands entirely on me, and the temptation to keep refining rather than shipping is harder to resist when it is your own name on the product.