LLMs have brought new hope to the hearts of a plethora of people that they can finally build any app they can imagine in seconds. Of course, we cannot completely ignore the truth value of this statement, and just like Lotfi Zadeh proposed in his work on fuzzy logic, truth doesn't need to be absolutely 0 or 1.

Despite my pessimistic attitude of believing coding is not solved, I will dedicate the majority of this post to talking about how to utilise the productivity gains LLM tools have brought to coding to gain an edge as a solo developer and build a truly valuable product. The rest is a matter of luck and how much marketing effort you're willing to put in.

Refactor often and follow structure:

AI can produce something that looks nice but is spaghetti code inside. But you can even use AI tools to refactor your code into one of the maintainable structures. Personally, I like to use Hexagonal architecture.

Good testing and coverage prevents AI from accidentally changing unrelated code:

I have noticed multiple times that when I let an agent run free, it had continued and changed a part of the code I hadn't asked it to, in an unintentional way. I know it's unintentional because the change had nothing to do with the task. However, this happens less often if I have good unit or integration test coverage for my changes. That being said, make sure you use automated testing (mainly unit and integration) to keep core functionality intact between your changes. Ask AI to set up a coverage report and aim for 100% on your code. You might think this is excessive since not every file needs a test, which I completely agree with. However, in that case, you can exclude all such files from the coverage report so you only track coverage of core logic files.

Go live quickly

One of the mistakes people make while building solo is delaying going live, or at least deploying their app. This is a completely incorrect approach to gaining feedback. Your first feedback won't come from your users; it will come from your own processes. In software engineering, this is called vertical or horizontal slices. The thickness of your vertical slice is up to you; your main goal is to connect start to end. Unfortunately, in some cases this might not be possible (such as app development, where you have less control over your future release dates).

In summary of vibe coding tips

You might have even better suggestions about your workflow. Following these steps will help you fight the slop that AI generates and turn it into something maintainable and extensible. This is important for my main hypothesis. My hypothesis Now, here I should say that I have personally not built a successful SaaS, so all of this is just a hypothesis, but I believe it can work if more people try it. If you follow good coding practices and write maintainable code, then, by extending your work into something more complex (by going depth-first instead of breadth-first), you might gain an edge over existing competitors by doing something very complex as well as very niche. You can only achieve this via 'good complexity' in your code. If you have been using LLMs to write code for as long as I have, you probably have built a lot of toy projects and have a folder on your computer where they all pile up. Well, I think it's time to bring them back, too. Some might have seen that AI recently tried to copy the code of an open-source compiler and achieved some level of success.

Surely, if it had tried to start from scratch, it would have failed more spectacularly, but having something to copy from makes the job incredibly easier. So let AI use your past code to replicate certain functionality that you can combine into your tool in a coherent way. I hypothesise that if you keep building useful tools in a connected way, you are providing unique value.

Chances are your assumptions about user behaviour have been wrong a few times, if you've read this far and you really enjoy building with AI. My understanding is that it's very hard to predict what a group of users likes to do in any amount of detail. For example, when I started working on Oyren.ai, I thought that, as a student, I use AI in a specific way, so maybe everyone else does the same. But this assumption was wrong. Even if you get the assumption right, building a good UI/UX that realises it is hard. So a good approach in this case is to focus on building tools that allow you to iterate quickly. A good engineer has to have good skills as well as good tools.

Conclusions

We all love to build, but some of us might enjoy the engineering aspect of it more. If you want to keep doing more of that while still building something that provides value, I hope you find my ideas worthy of your time. Reach out at [email protected] for comments/questions.

Keywords

#pdf-to-ai,#pdf-reader-ai-free, #pdf-reader-free-credits, #pdf-reader-software

So you want to build without doing any market research or social media marketing