I'm curious how you go about developing a new feature.
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.
Ask HN: Indie devs, what is your development process?
1–10 of 27 posts
Re: Ask HN: Indie devs, what is your development process?
#2I 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.
Re: Ask HN: Indie devs, what is your development process?
#3I 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 wri…
> 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.
Re: Ask HN: Indie devs, what is your development process?
#4Process?
Seriously, one of the great things about being a solo dev is not having a process.
Re: Ask HN: Indie devs, what is your development process?
#5Not 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.
Re: Ask HN: Indie devs, what is your development process?
#6Oh. 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.
Re: Ask HN: Indie devs, what is your development process?
#7I 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 wri…
> 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…
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.")
Re: Ask HN: Indie devs, what is your development process?
#8Process? 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.
Re: Ask HN: Indie devs, what is your development process?
#9Validation 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.
Re: Ask HN: Indie devs, what is your development process?
#10Sometimes 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.