Ask HN: Indie devs, what is your development process?

Not sure if you care about validation. If not skip to 2.<p>1. Anybody want it?<p>First I pitch the rough idea to a few paying customers. If they are lukewarm on it I set it aside.<p>If they are warm on it I set it aside.<p>If they say they want it I set it aside.<p>When some time goes by and they check in and say “whatever happened with (feature) I consider it validated.”<p>2. Be bad at it<p>Give myself permission to make the absolute worst version of it.<p>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.<p>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.<p>3.beta test the MEV<p>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.<p>I give it to those users who were interested.<p>I watch them on hot jar.<p>4. Tea leaves<p>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.<p>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.<p>5. Users of Software<p>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.<p>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.<p>Or maybe you’re not that surprised because you’ve voted in America zing I went political at the end.

1. I have <i>deep</i> long discussions with the customer to understand the <i>business</i> problem they want solved. Usually over a nice coffee in a relaxed environment.<p>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!<p>3. The customer <i>pays</i> 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.<p>4. If they are happy with the spec I then negotiate a contract and payment terms. This <i>always</i> 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.<p>5. I quickly implement what I call the “skeleton” of the application. All use cases are implemented with a minimum ugly&#x2F;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).<p>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.<p>It works well. It isn’t perfect (what is?) but it has been successful for me.

Process?<p>Seriously, one of the great things about being a solo dev is <i>not</i> having a process.

I too favor a &quot;code early&quot; 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&#x27;m using. It&#x27;s good to learn that early on.<p>I&#x27;m a test-first fan, so I start coding by doing a small test of a small bit of functionality. I&#x27;m not doctrinaire, so sometimes I&#x27;ll write functionality before tests, but usually not. And I write tests pretty soon after if I don&#x27;t write them first.<p>I use GIT, even on personal projects and have moved away from Gitflow to a CI&#x2F;CD branching strategy.<p>I&#x27;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.<p>Most importantly my comments document my intention, not what I&#x27;m doing. I can tell I&#x27;m incrementing a variable by looking at the code, but if it&#x27;s non-obvious why I&#x27;m incrementing it, I&#x27;ll writa a comment about that.<p>Test first and documenting intent help me regain context if I have to put the project down and pick it back up later.<p>I sometimes use code coverage tools, but I&#x27;ve gotten pretty meh about it lately.<p>I&#x27;m learning TLA+, but already use KAMI on hardware projects. I think there&#x27;s a lot of potential upside w&#x2F; verification tools, but dang if it&#x27;s not a little brain-bending sometimes.<p>I&#x27;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&#x27;t use Clojure more, it&#x27;s a perfectly fine language.

Oh. One other thing. I tend to go backwards. UX first. Then API. Then whatever fuels it.<p>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.

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&#x2F;CSS&#x2F;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<p><a href="https:&#x2F;&#x2F;pketh.org&#x2F;how-i-build.html" rel="nofollow">https:&#x2F;&#x2F;pketh.org&#x2F;how-i-build.html</a>

Sometimes it&#x27;s really hard or not worth to get proper feedback even when you have a userbase.<p>If I believe a feature is interesting or may be useful, I&#x27;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&#x27;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.<p>After it&#x27;s clearer what the new feature is, I go back to the existing project&#x27;s repo an start building it. I raid whatever code is useful from the prototype as I do so.<p>In the case of a completely new project, I still start with a prototype and frequently discard and rewrite it after getting more clarity.<p>I don&#x27;t write any tests during the sketching&#x2F;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.<p>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 <i>never</i> actually do it to that level, but my level of released bugs is low enough that what I <i>actually</i> do is good enough.<p>But what it <i>does</i> give me is a template to follow and adjust as the circumstances require.<p>So I always start with requirements. Requirements are my goals, and they are always in my mind throughout the rest of the process.<p>Then I design. I design the UI, UX, implementation, and tests, and I <i>iterate</i> between them until I get to a fixed point where everything is in a great local maximum.<p>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.<p>After I have a design in hand, I do <i>not</i> start coding the feature. Instead, I figure out what technical debt the codebase now has.<p>That may not make sense, so let me explain.<p>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 <i>intention</i> to add the feature means that the codebase now has technical debt <i>relative to where it should be for the feature</i>.<p>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.<p>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.<p>Then I get the tests passing.<p>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&#x27;s easier for me to notice them too.<p>I fix the crashes found by AFL++ (most of them failing asserts), add the formerly crashing test cases to my test suite, and repeat.<p>Once AFL++ runs to &quot;completion&quot; (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.<p>But then I still run static analysis on it.<p>Then I add the feature to my NEWS.md file, increment the version appropriately, and put out a release.<p>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&#x27;ll write down things that future contributors, including myself, may need to know about that feature, especially its implementation.<p>Missing documentation is technical debt, and I have near zero technical debt.<p>Of course, you may take issue with my assertion that I have zero or near zero technical debt, but this is basically true.<p>The reason is that I&#x27;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 <i>everything</i> I see before getting to coding.<p>This can be annoying and discouraging at times; I have phases where I stop programming for a few days or a week because I&#x27;m not looking forward to a refactor that I need to do, but I can&#x27;t continue without it because I&#x27;m a perfectionist. But it does mean that I have very little technical debt.<p>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&#x27;m done struggling through removing the technical debt, it&#x27;s great!<p>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.<p>This process also means that I cannot work with other people; I actually can&#x27;t keep a job in the industry. So don&#x27;t adopt this process if you <i>do</i> work in industry.<p>[1]: <a href="https:&#x2F;&#x2F;gavinhoward.com&#x2F;uploads&#x2F;process.md" rel="nofollow">https:&#x2F;&#x2F;gavinhoward.com&#x2F;uploads&#x2F;process.md</a><p>[2]: <a href="http:&#x2F;&#x2F;antirez.com&#x2F;news&#x2F;124" rel="nofollow">http:&#x2F;&#x2F;antirez.com&#x2F;news&#x2F;124</a><p>[3]: <a href="https:&#x2F;&#x2F;git.yzena.com&#x2F;gavin&#x2F;bc&#x2F;commit&#x2F;eb0cd870b91f3ad2a834f224cc077e6adcd4ce89" rel="nofollow">https:&#x2F;&#x2F;git.yzena.com&#x2F;gavin&#x2F;bc&#x2F;commit&#x2F;eb0cd870b91f3ad2a834f2...</a>