Ask HN: How Do You Usually Plan and Approach Your Solo Projects?

[OulaX]

I'm a solo freelance software engineer, and it's my 3'rd year working.

I am constantly improving my coding and testing skills and I can feel the improvements day after day.

However, one part that I am still facing trouble with, is project planning and actually executing that plan.

I can't decide whether I should start with a DB schema or jump right in to experimenting. I can't decide whether I should develop the frontend first or the backend. I can't decide what steps to take after I have an MVP.

I want to learn how other developers approach these tasks in their projects, maybe I could learn something new from everyone!

[leros]

I don't project manage and code at the same time. I find that leads to bouncing around and not making effective progress. I treat myself like a small team of individuals.

I'll dedicate time to just project management. I'll become a project manager and lay out the requirements, break that down into tasks, and prioritize. Then I'll take one task and focus on that. For example, an early task might be designing the overall system architecture, so I'll become a software architect and work on that. A next task might be coding a feature. So I'll become a developer and code up that feature.

If I ever find myself mixing roles into a single work session, it's usually time to take a step back and organize myself a bit more.

[muzani]

This was how I leveled up at solo work. At least 20% of the time goes into planning everything out. Aim before firing. You can easily spend hundreds of hours coding a thing nobody wants. That's how everyone gets burned out. Most of the docs for these are written on the train, in queues, in bed, so I can just jump into coding when I'm at an actual keyboard.

[muzani]

On a high level, decide what you want to do. What's the essence of your product? The skeleton. This should never change. A business model canvas is one technique, but there are others. I can literally go on for hours and hours on this, feel free to drop an email.

The pro way would be to tackle the riskiest. Is it hard to make money? Hire a designer, mock the UI, show the dummy app to the customer. This is what I'd do as a freelancer being paid hour to hour.

The casual way is tackle whatever you feel is easiest. I like UI and colors, so I start there. Some people like data structures.

Build a system. Systems are not about the components but how they connect. Components can be swapped in and out. So an API is actually one way to start.

Abstract out components as much as possible. I replaced my caching system with a memory cache (aka put everything in variables) even though the proper way would be a disk cache. It does the job.

Build interconnections first though, then you swap the parts in and out.

"I can't decide what steps to take after I have an MVP."

This probably means you won't have a MVP, lol. MVP means minimum. You need to promise something to someone and then deliver on that promise. The purpose of a lot of UI, UX, juice, etc, is to make them intrigued enough to make them a promise.

A lot of people aren't mindful of what the customer expects. You can get this from reviews and customer research. One group is price sensitive and don't care what organs are in their hot dogs. Another wants calorie count. Another only cares about carb count.

Those features should be in the marketing. Screenshots are marketing. Figure out what they want, promise them the thing, have QA gates to check that the thing meets the promises, then sell the product that does what is promised.

[eternityforest]

My (possibly unpopular opinion) process is something like:

1. Look for other stuff that already does what I want, or could be extended to do so. I'd rather make a PR for your project than start a new one.

2. Look for tech building blocks to do the thing. I do this before thinking about architecture, I want my design to fit popular tools, not obscure tools that fit my design. Test them out if I haven't used them before, ensure they actually work.

3. Look at protocols and data formats used in similar things. I probably want to stay compatible and keep a similar UI.

4. Sketch what the UI and workflow should be. I don't want to design something that is a poor match for the UI I have in mind and requires ugly glue code.

5. List any nice to have stuff I want to be sure I can do later

6. Write the backend functionality and whatever test code I need for it. A git repo should be there from the start.

7. Do the frontend

[romanhn]

Start with a most basic model - 1-2 tables ideally. Build a basic backend to handle this data. Now build a basic frontend to display it. You now have version 0.0000..1 of your project! Now start adding complexity one bit at a time. Avoid the temptation to boil the ocean and come up with all the requirements upfront. Embrace the MVP life, and iterate, iterate, iterate.

[bjw181]

Depends on the project. If its monetary, you need to approach it with a business mindset and the Domain Drive Design standard works well here (although it can be overkill at times)

For everything else I think design should drive the backend development. Annotate some figma mockups and you can build your schema off of that.

[saasjosh]

I just start coding, then if it sucks, I throw away the code, and start from scratch. Github branches help with this.

When I start from scratch again, I usually do much better than the first time because you get to use all the experience from the previous iteration to make the current out better.