Ask HN: Indie devs, what is your development process?
26 comments
Not sure if you care about validation. If not skip to 2.
1. Anybody want it?
First I pitch the rough idea to a few paying customers. If they are lukewarm on it I set it aside.
If they are warm on it I set it aside.
If they say they want it I set it aside.
When some time goes by and they check in and say “whatever happened with (feature) I consider it validated.”
2. Be bad at it
Give myself permission to make the absolute worst version of it.
That frequently involves writing a one page max description of it, and then asking myself “okay how much of this could I cut before it was literally doing nothing.” But if I’m feeling bored I just start coding.
This version has no error checking. No tests. No capacity for large requests. No logging. Nothing. It just prays beyond all reason that the user doesn’t do anything silly that breaks it.
3.beta test the MEV
I just made it up. It’s not a real acronym. most execrable version. It fits because it does feel like something I excreted. I hate it. I’m embarrassed. My impostor syndrome is no longer a syndrome it is just accurate identification and classification.
I give it to those users who were interested.
I watch them on hot jar.
4. Tea leaves
This is the hard part. If they are enthused great. But if not You kinda have to sense whether or not their dissatisfaction is because it’s an MEP.
If you’ve done it right, however, and found something they super want they will actually struggle through it to get that thing done. Sometimes the MEP isn’t far off from an MVP. Sometimes their satisfaction is enough to convince you not to do the rest of the stuff you thought was necessary in your on paper Valhalla take.
5. Users of Software
I often forget that your average software user does not have our relationship with software. They don’t see the amazing version in your head so the crap version feels like magic.
You’d be surprised how hard people will work with a subpar system with the hope that it’ll work out for them, both from optimism but also from a lack of viable alternatives.
Or maybe you’re not that surprised because you’ve voted in America zing I went political at the end.
1. Anybody want it?
First I pitch the rough idea to a few paying customers. If they are lukewarm on it I set it aside.
If they are warm on it I set it aside.
If they say they want it I set it aside.
When some time goes by and they check in and say “whatever happened with (feature) I consider it validated.”
2. Be bad at it
Give myself permission to make the absolute worst version of it.
That frequently involves writing a one page max description of it, and then asking myself “okay how much of this could I cut before it was literally doing nothing.” But if I’m feeling bored I just start coding.
This version has no error checking. No tests. No capacity for large requests. No logging. Nothing. It just prays beyond all reason that the user doesn’t do anything silly that breaks it.
3.beta test the MEV
I just made it up. It’s not a real acronym. most execrable version. It fits because it does feel like something I excreted. I hate it. I’m embarrassed. My impostor syndrome is no longer a syndrome it is just accurate identification and classification.
I give it to those users who were interested.
I watch them on hot jar.
4. Tea leaves
This is the hard part. If they are enthused great. But if not You kinda have to sense whether or not their dissatisfaction is because it’s an MEP.
If you’ve done it right, however, and found something they super want they will actually struggle through it to get that thing done. Sometimes the MEP isn’t far off from an MVP. Sometimes their satisfaction is enough to convince you not to do the rest of the stuff you thought was necessary in your on paper Valhalla take.
5. Users of Software
I often forget that your average software user does not have our relationship with software. They don’t see the amazing version in your head so the crap version feels like magic.
You’d be surprised how hard people will work with a subpar system with the hope that it’ll work out for them, both from optimism but also from a lack of viable alternatives.
Or maybe you’re not that surprised because you’ve voted in America zing I went political at the end.
Do you ever code something for yourself, or are there always customers involved?
Oh sure, all the time. But that's always a bit wild-west, since I'm more or less doing it for fun, then my approach is always "Well what do I want to do, emotionally" so it's hard to advise on fun projects. It'd be like "What's fun for you to do?"
I guess if I had any kind of advice for that kind of thing it might be this: I've realised that even in my fun projects, there's a 10% crappy annoying tedious thing that -very- frequently stops me from finishing the fun projects.
A potentially bit good of advice would be to do that thing first, use all the "new fresh code base" enthusiasm to BURN through the code you're gonna hate so that it's just fun from then on.
I guess if I had any kind of advice for that kind of thing it might be this: I've realised that even in my fun projects, there's a 10% crappy annoying tedious thing that -very- frequently stops me from finishing the fun projects.
A potentially bit good of advice would be to do that thing first, use all the "new fresh code base" enthusiasm to BURN through the code you're gonna hate so that it's just fun from then on.
If you're referring to a product feature the dev wants versus a feature the customer wants, I don't think there will ever be a case when the former takes priority
1. I have deep long discussions with the customer to understand the business problem they want solved. Usually over a nice coffee in a relaxed environment.
2. I document it in a Spec and make sure the customer reviews and understands exactly what they will get. Again, while enjoying good coffee!
3. The customer pays up front for this initial Spec work. If they don’t want to pay up front I walk away. I don’t work with customers who doesn’t understand that work costs money.
4. If they are happy with the spec I then negotiate a contract and payment terms. This always includes an upfront payment. Usually 10%. If they don’t want to pay a percentage upfront I walk away. Cheap customers are not worth the pain. The rest is paid based on milestone deliverables. I always make sure that milestones are backend heavy so that I have a time buffer if needed.
5. I quickly implement what I call the “skeleton” of the application. All use cases are implemented with a minimum ugly/super simple UI and an in-memory hash map “database” for storage. Test cases cover all use cases end-to-end. I use an in-house code generator to make this step fast (80% of the code is usually generated).
6. I then iterate, refine, and improve the whole application step by step until it is done. With regular demos to the customer getting feedback on progress.
It works well. It isn’t perfect (what is?) but it has been successful for me.
2. I document it in a Spec and make sure the customer reviews and understands exactly what they will get. Again, while enjoying good coffee!
3. The customer pays up front for this initial Spec work. If they don’t want to pay up front I walk away. I don’t work with customers who doesn’t understand that work costs money.
4. If they are happy with the spec I then negotiate a contract and payment terms. This always includes an upfront payment. Usually 10%. If they don’t want to pay a percentage upfront I walk away. Cheap customers are not worth the pain. The rest is paid based on milestone deliverables. I always make sure that milestones are backend heavy so that I have a time buffer if needed.
5. I quickly implement what I call the “skeleton” of the application. All use cases are implemented with a minimum ugly/super simple UI and an in-memory hash map “database” for storage. Test cases cover all use cases end-to-end. I use an in-house code generator to make this step fast (80% of the code is usually generated).
6. I then iterate, refine, and improve the whole application step by step until it is done. With regular demos to the customer getting feedback on progress.
It works well. It isn’t perfect (what is?) but it has been successful for me.
How detailed are you in the spec?
As detailed as needed for the client to understand exactly what they will get delivered. However 100% focused on solving the biz problem not UI details or whatever.
Process?
Seriously, one of the great things about being a solo dev is not having a process.
Seriously, one of the great things about being a solo dev is not having a process.
Amen. I try to do things fairly rough and allow myself to quickly pivot if I’m feeling like what I’m building will take too long and there may be other more important tasks.
The one bit of process I do follow is I generally write up some quick notes about what I’m trying to achieve. What is the purpose of this feature (i.e. what is the customer goal or marketing goal) and then I write up how I’m thinking of solving it. That gives me enough context in case I revisit things later and forget why I even started it.
From there I usually think about the design (UI and architecture) and sketch out a bunch of things. I’ll go for walks and think about it a lot.
Once I have enough to code, I’ll make a todo list in a markdown file (usually the same one with the notes from earlier). I just keep checking off tasks in there and adding new ones.
Eventually I start getting most of the tasks done and often there’s enough to either just test it/ship it or not. I just go with a gut check as to whether I should add more polish or not, but I try to cut myself off once the main use case works and looks decent.
I usually test for a day or two before shipping.
This is how I coded up most of the recent features of my app. (See my profile for a link.)
To be honest, writing the features is the easy part. The hard part is marketing and finding users.
The one bit of process I do follow is I generally write up some quick notes about what I’m trying to achieve. What is the purpose of this feature (i.e. what is the customer goal or marketing goal) and then I write up how I’m thinking of solving it. That gives me enough context in case I revisit things later and forget why I even started it.
From there I usually think about the design (UI and architecture) and sketch out a bunch of things. I’ll go for walks and think about it a lot.
Once I have enough to code, I’ll make a todo list in a markdown file (usually the same one with the notes from earlier). I just keep checking off tasks in there and adding new ones.
Eventually I start getting most of the tasks done and often there’s enough to either just test it/ship it or not. I just go with a gut check as to whether I should add more polish or not, but I try to cut myself off once the main use case works and looks decent.
I usually test for a day or two before shipping.
This is how I coded up most of the recent features of my app. (See my profile for a link.)
To be honest, writing the features is the easy part. The hard part is marketing and finding users.
Sure thing but it's good to have at least a little something to prevent too much refactoring later.
I too favor a "code early" strategy. Though I always write down sample data inputs and outputs on paper or in a text file. Sometimes I realize I misunderstood some aspect of an API I'm using. It's good to learn that early on.
I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first.
I use GIT, even on personal projects and have moved away from Gitflow to a CI/CD branching strategy.
I'm a bit of a weirdo and write basic usage docs pretty early in the process. I average a couple paragraphs per file, just an overview of what the functions in the file are supposed to do. That way I can get away with shorter per-function comments.
Most importantly my comments document my intention, not what I'm doing. I can tell I'm incrementing a variable by looking at the code, but if it's non-obvious why I'm incrementing it, I'll writa a comment about that.
Test first and documenting intent help me regain context if I have to put the project down and pick it back up later.
I sometimes use code coverage tools, but I've gotten pretty meh about it lately.
I'm learning TLA+, but already use KAMI on hardware projects. I think there's a lot of potential upside w/ verification tools, but dang if it's not a little brain-bending sometimes.
I've also rediscovered my love of Lisp in the last 5 years, so am using Janet or Scheme a lot for personal projects. Not sure why I don't use Clojure more, it's a perfectly fine language.
I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first.
I use GIT, even on personal projects and have moved away from Gitflow to a CI/CD branching strategy.
I'm a bit of a weirdo and write basic usage docs pretty early in the process. I average a couple paragraphs per file, just an overview of what the functions in the file are supposed to do. That way I can get away with shorter per-function comments.
Most importantly my comments document my intention, not what I'm doing. I can tell I'm incrementing a variable by looking at the code, but if it's non-obvious why I'm incrementing it, I'll writa a comment about that.
Test first and documenting intent help me regain context if I have to put the project down and pick it back up later.
I sometimes use code coverage tools, but I've gotten pretty meh about it lately.
I'm learning TLA+, but already use KAMI on hardware projects. I think there's a lot of potential upside w/ verification tools, but dang if it's not a little brain-bending sometimes.
I've also rediscovered my love of Lisp in the last 5 years, so am using Janet or Scheme a lot for personal projects. Not sure why I don't use Clojure more, it's a perfectly fine language.
> I too favor a "code early" strategy. Though I always write down sample data inputs and outputs on paper or in a text file. Sometimes I realize I misunderstood some aspect of an API I'm using. It's good to learn that early on.
> I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first.
I also do this and find it very helpful in breaking down assumptions. I will add that it has been, in my experience, best to do _everything_ to break down assumptions of any kind first - you don't want to find out far later in the process that some technical solution you had isn't viable for your needs, or even that some business-oriented solution doesn't pan out.
> I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first.
I also do this and find it very helpful in breaking down assumptions. I will add that it has been, in my experience, best to do _everything_ to break down assumptions of any kind first - you don't want to find out far later in the process that some technical solution you had isn't viable for your needs, or even that some business-oriented solution doesn't pan out.
That got me thinking. The reason I moved to test-first (or test-early) is I've coded myself into a corner with respect to tests, that is, I wrote code that was super-hard to test. I think that falls under "breaking down assumptions" -- I assumed I would be able to easily test code I was writing. I'm going to start using "BDA" as an acronym at work (and see if anyone thinks I mean "Battle Damage Assessment.")
Oh. One other thing. I tend to go backwards. UX first. Then API. Then whatever fuels it.
If I go the other way around I -inevitably- forget some stuff that is crucial for the front end implementation, whereas it’s hard to forget how it supposed to work for the user.
If I go the other way around I -inevitably- forget some stuff that is crucial for the front end implementation, whereas it’s hard to forget how it supposed to work for the user.
That's funny because I always start at the database level and work up. If I start in the frontend it ends up getting rewritten too often.
That's SUPER interesting. We should form like Voltron. But also I wonder if that's a meaningful 'heuristic' to use both in analysing ones own performance but also in coaching others.
Validation for demand comes first, but sometimes the product starts with a new user experience that opens more demand for old functionality (think the swipe for tinder). Since I work on consumer products - for brand new ideas I prototype the user experience first. I think in HTML/CSS/JS so it’s easy to just do it that way. Then I start playing with that as a user - maybe store data locally, and make it useful and easy. Once that’s polished and I find myself using my own product for a while (or whoever requested the feature does), I start building a proper backend in go with testing, api, performance, database, etc.
I wrote a blog post about this very topic, including how I balance user needs with my own aspirations
https://pketh.org/how-i-build.html
https://pketh.org/how-i-build.html
Sometimes it's really hard or not worth to get proper feedback even when you have a userbase.
If I believe a feature is interesting or may be useful, I'll just spend least effort to create UI and make the feature barely useable for the simplest use case. Pretty much like a demo feature to hook up the users. It's actually pretty helpful to have bugs and limitations. If users find it could potentially solve their problems, or care about it, they will reach out and the ball can be rolling.
If I believe a feature is interesting or may be useful, I'll just spend least effort to create UI and make the feature barely useable for the simplest use case. Pretty much like a demo feature to hook up the users. It's actually pretty helpful to have bugs and limitations. If users find it could potentially solve their problems, or care about it, they will reach out and the ball can be rolling.
I usually start with an exploratory prototype and go back and forth between coding and sketching things out in my notebook.
After it's clearer what the new feature is, I go back to the existing project's repo an start building it. I raid whatever code is useful from the prototype as I do so.
In the case of a completely new project, I still start with a prototype and frequently discard and rewrite it after getting more clarity.
I don't write any tests during the sketching/prototyping phase.
After it's clearer what the new feature is, I go back to the existing project's repo an start building it. I raid whatever code is useful from the prototype as I do so.
In the case of a completely new project, I still start with a prototype and frequently discard and rewrite it after getting more clarity.
I don't write any tests during the sketching/prototyping phase.
I don’t keep a to-do list. I keep most ideas in my head. When I have development time I choose the most important feature, imagining it was the last feature I could develop.
I wireframe the UX, and when I’m satisfied I implement it. I test and dogfood until I have almost zero doubts about the lack of bugs and potential user complaints, and ship it.
I wireframe the UX, and when I’m satisfied I implement it. I test and dogfood until I have almost zero doubts about the lack of bugs and potential user complaints, and ship it.
Terminal + Sublime.
My ideal process ([1]) is...tedious. I never actually do it to that level, but my level of released bugs is low enough that what I actually do is good enough.
But what it does give me is a template to follow and adjust as the circumstances require.
So I always start with requirements. Requirements are my goals, and they are always in my mind throughout the rest of the process.
Then I design. I design the UI, UX, implementation, and tests, and I iterate between them until I get to a fixed point where everything is in a great local maximum.
If I encounter a local maximum that is bad or merely good, I throw out the design and start again from scratch and repeat as necessary. This is less necessary as the project ages because my intuition for the project increases.
After I have a design in hand, I do not start coding the feature. Instead, I figure out what technical debt the codebase now has.
That may not make sense, so let me explain.
Designing first means that I have a good idea of what needs to change in the codebase before the feature can be implemented easily. Before I wanted to implement the feature, the codebase had zero, or near zero, technical debt. But the intention to add the feature means that the codebase now has technical debt relative to where it should be for the feature.
So before I implement the feature, I tackle this new technical debt first, and when I am done, I use my full test suite, which has extremely high line, branch, and path coverage, to ensure that the refactor did not introduce new bugs.
Once I am satisfied with that, I implement the feature and add its tests. This includes adding as many asserts as I can to test the assumptions the code is making, both for documentation purposes and for quickly finding bugs with the test suite.
Then I get the tests passing.
Then I fuzz with AFL++, with the asserts turned on so that it will be as crash-happy as possible. This means that bugs are more easily found by AFL++, and it's easier for me to notice them too.
I fix the crashes found by AFL++ (most of them failing asserts), add the formerly crashing test cases to my test suite, and repeat.
Once AFL++ runs to "completion" (not finding any more test cases after having gone through basically all of the ones it found) without crashing, I have great confidence that the feature is robust.
But then I still run static analysis on it.
Then I add the feature to my NEWS.md file, increment the version appropriately, and put out a release.
However, woven throughout all of the steps is documentation. I document the requirements. I document the design. I document the new code, including a full Doxygen comment for every new function and type, as well as updated doc comments for any existing code that changed. I also comment the actual code heavily, using [2] as a model. I'll write down things that future contributors, including myself, may need to know about that feature, especially its implementation.
Missing documentation is technical debt, and I have near zero technical debt.
Of course, you may take issue with my assertion that I have zero or near zero technical debt, but this is basically true.
The reason is that I'm a perfectionist with my code. When I go to make changes, I would struggle if I did not fix any imperfections I see. For an example, see [3]. So I do actually remove everything I see before getting to coding.
This can be annoying and discouraging at times; I have phases where I stop programming for a few days or a week because I'm not looking forward to a refactor that I need to do, but I can't continue without it because I'm a perfectionist. But it does mean that I have very little technical debt.
It turns out that a lack of technical debt is a superpower; it makes features easy to add and keeps velocity high. So once I'm done struggling through removing the technical debt, it's great!
This process is special, and it really can only work for someone that is as much of a perfectionist as me, and if someone does, they will have to be used to not implementing as many features because while velocity is high, I still spend copious amounts of time on refactoring and on tests, although that does increase velocity too by making it easy to do large refactors without fear.
This process also means that I cannot work with other people; I actually can't keep a job in the industry. So don't adopt this process if you do work in industry.
[1]: https://gavinhoward.com/uploads/process.md
[2]: http://antirez.com/news/124
[3]: https://git.yzena.com/gavin/bc/commit/eb0cd870b91f3ad2a834f2...
But what it does give me is a template to follow and adjust as the circumstances require.
So I always start with requirements. Requirements are my goals, and they are always in my mind throughout the rest of the process.
Then I design. I design the UI, UX, implementation, and tests, and I iterate between them until I get to a fixed point where everything is in a great local maximum.
If I encounter a local maximum that is bad or merely good, I throw out the design and start again from scratch and repeat as necessary. This is less necessary as the project ages because my intuition for the project increases.
After I have a design in hand, I do not start coding the feature. Instead, I figure out what technical debt the codebase now has.
That may not make sense, so let me explain.
Designing first means that I have a good idea of what needs to change in the codebase before the feature can be implemented easily. Before I wanted to implement the feature, the codebase had zero, or near zero, technical debt. But the intention to add the feature means that the codebase now has technical debt relative to where it should be for the feature.
So before I implement the feature, I tackle this new technical debt first, and when I am done, I use my full test suite, which has extremely high line, branch, and path coverage, to ensure that the refactor did not introduce new bugs.
Once I am satisfied with that, I implement the feature and add its tests. This includes adding as many asserts as I can to test the assumptions the code is making, both for documentation purposes and for quickly finding bugs with the test suite.
Then I get the tests passing.
Then I fuzz with AFL++, with the asserts turned on so that it will be as crash-happy as possible. This means that bugs are more easily found by AFL++, and it's easier for me to notice them too.
I fix the crashes found by AFL++ (most of them failing asserts), add the formerly crashing test cases to my test suite, and repeat.
Once AFL++ runs to "completion" (not finding any more test cases after having gone through basically all of the ones it found) without crashing, I have great confidence that the feature is robust.
But then I still run static analysis on it.
Then I add the feature to my NEWS.md file, increment the version appropriately, and put out a release.
However, woven throughout all of the steps is documentation. I document the requirements. I document the design. I document the new code, including a full Doxygen comment for every new function and type, as well as updated doc comments for any existing code that changed. I also comment the actual code heavily, using [2] as a model. I'll write down things that future contributors, including myself, may need to know about that feature, especially its implementation.
Missing documentation is technical debt, and I have near zero technical debt.
Of course, you may take issue with my assertion that I have zero or near zero technical debt, but this is basically true.
The reason is that I'm a perfectionist with my code. When I go to make changes, I would struggle if I did not fix any imperfections I see. For an example, see [3]. So I do actually remove everything I see before getting to coding.
This can be annoying and discouraging at times; I have phases where I stop programming for a few days or a week because I'm not looking forward to a refactor that I need to do, but I can't continue without it because I'm a perfectionist. But it does mean that I have very little technical debt.
It turns out that a lack of technical debt is a superpower; it makes features easy to add and keeps velocity high. So once I'm done struggling through removing the technical debt, it's great!
This process is special, and it really can only work for someone that is as much of a perfectionist as me, and if someone does, they will have to be used to not implementing as many features because while velocity is high, I still spend copious amounts of time on refactoring and on tests, although that does increase velocity too by making it easy to do large refactors without fear.
This process also means that I cannot work with other people; I actually can't keep a job in the industry. So don't adopt this process if you do work in industry.
[1]: https://gavinhoward.com/uploads/process.md
[2]: http://antirez.com/news/124
[3]: https://git.yzena.com/gavin/bc/commit/eb0cd870b91f3ad2a834f2...
Interesting to see that you care about technical debt even outside a team.
Technical debt has killed one of my projects once and I should really work to eliminate or at least minimize it.
Thanks for sharing.
Technical debt has killed one of my projects once and I should really work to eliminate or at least minimize it.
Thanks for sharing.
This is specifically for solo devs.
As for me, sometimes I write down a brief overview, add some tasks to my todo list, and start coding right way.
Please share yours.