Pros and Cons of Solo Development(johnjeffers.com) |
Pros and Cons of Solo Development(johnjeffers.com) |
Everything else boils down to this.
I disagree; it's even more obvious with AI that, with AI, a solo dev can go even faster, but still, with AI, you need a team to go further.
Plus it is much healthier to have a social life outside of work. Talk about something else, no algos!
Smaller ideas need not be approved, or held back by schedule pressure from bean counters. Just Do It. :). It's the small corrections which end up polishing the product as good as "professional usability studies".
It makes the difference between a tool that is a pleasure to use and one that causes dread.
Separately, I hope the author of this project is able recognize how this project might be able to grow sustainably. Its a hard thing to know that you won't be able to work on something forever, and either building a community who wants to maintain a core project or having some company pay to maintain it could be a good idea. Linus isn't going to be around forever, but I expect that linux will outlive him by a good margin.
The more likely outcome is that something happens to me and I can't maintain it anymore. But if there's sufficient interest in keeping it going, anyone can fork it and pick up where I left off.
I'd say responsibility is the same for me as I've only worked at small companies as a generalist. But yeah I suspect if you come from big tech land, being the everything person might be super tough to get used to.
- do everything you can to keep burnout at bay
- you do, in fact, need a holiday
- hyperfocus is not your friend, ever; if you feel you can’t put it down, you must put it down
- never delete emails; the one thing you can guarantee is that you will need an email you deleted
- if you look back at your notes and they are not instantly obvious, rewrite them while you still remember what you meant, because one day you won’t
- you might be selling your abilities but you should never rely on them yourself; you do need systems
- you can fall out of love with the thing you are best at
- listen to your friends when they sell your talents; if they say you can do a thing, who are you to argue?
- three days of fully billable work per week is already too risky to gamble on, so:
- you are not charging enough
- YOU ARE NOT CHARGING ENOUGH
- FFS do you even listen? You’re not charging enough
I had a $5/month thing. Made a $20/month option that barely had more features. Sold lotsa seats.
Rewrote it. $10 and $50 plans. $50 is most popular.
But a day after I launched I got a new payment for $360. Damn, I thought, Claude must've screwed something up.
Nope, just somebody going straight into the Yearly option of the $50 (that I hadn't realized Claude added (with a discount)).
i assume most people are just against the ad-driven telemetry
Actually getting job interviews can be difficult. It helps to find the email associated with the person hiring, that way you can email them directly to make sure your application actually gets seen.
Not because it’ll make you faster (which it can).
But because when it’s 2am and your server is crashing and you don’t understand the error messages and your solo business is melting down, with AI you have a virtual helper to get you through solving tough problems.
Nothing is worse than being alone and things are breaking and you don’t know what to do or who to talk too since you’re solo and don’t have anyone else to troubleshoot with.
AI can be your helper in those times of need.
So add telemetry and a request tracker like https://www.productboard.com/. This is not a solo vs team thing.
I don't really need to know how many people use the app. It would be cool to know, but not necessary.
If someone wants a feature, or a fix, they can open an issue.
On the backend... Why wouldn't you log every request that hits your server, and why wouldn't you already know what those requests mean? Why would you let your frontend make direct requests to any other server when you can just proxy it yourself and maintain control?
On the frontend... What's so hard about wrapping all your event listeners and periodically sending those logs back to your server?
That's not even scratching the surface, but even something this simple and easy to implement is already miles ahead of most free-tier telemetry offerings, and you retain full control.
As an independent developer, the advantage is that I can do a lot of different things. It's hard to go deep into one area, but I can work across many different kinds of projects—building drones, inspection equipment, testing gear, shopping malls, red-team work for security companies, smart farm control systems, home trading systems, apartment wall pads, POS, WMS, data collection for academic papers, and more. I've worked on quite a variety of projects and stacks. That's the upside. The downside is that it's hard to develop the same depth of expertise as a team-based developer. In reality, most of the work is just reading manuals and implementing things according to them.
Right now I'm working on creating a programming language, but I'm a little worried because everyone seems to be building languages with LLMs these days. Ultimately, a language needs to offer enough value for users to actually want to try it, and I'm not sure I can create something compelling enough to attract interest.
The machinery equipment work I usually do depends on factories expanding nearby, but lately the area I live in has been declining, so there's not much of that work anymore. Someday I'd like to build a project that people remember. But unlike Western developers, I'm far from the mainstream of programming, and my skills aren't that great either, so I'm not sure what to do or what would even be a good direction.
If I joined a company, I'd have to leave my area, but then rent would be hard to afford, and my workflow would be so different from theirs that I'm not sure it would work out. I feel like I've designed my career poorly. And it's not like I'd be able to get hired in this job market anyway
So, while I currently [mostly] agree, I think the / a next generation of agents might take that over a threshold and make solo development close enough to the equivalent of current 2-dev work to meaningfully change the equation. Furthermore I think that does not even need new models; I think current models with better "harness / tooling / system prompting / skills / etc." (whatever you may call the text files describing important procedures), might be able to fill most of that gap.
Obviously work that needs more than 2 devs planning might take even longer to fully solve with 1 dev + multiple agents, if ever.
My current mental model is that humans can very well think about and walk the boundary of problems, while [current] AI agents can fill the inside to some extent. If a problem has inherent "multi-dimensional boundaries", it might be hard for a person to imagine and walk it well to guide the agents. And I think most of the interesting problems fall in this category.
Surely that's both faster and further?
IMO AI agents are like a team of remote consultants that only talk shop and have no sense of humor.
It can mean the power of delegation and creativity. The worst kind of teams are monocular, democratically oriented teams where every member must be on and act in the same manner. It's great for efficiency, it's horrible for productivity and creativity.
1. A primary meaning, "Further" means "revenue" (or "profit"). You and your AI together can sit and create a competitor to Windows 11, do the marketing copy, a sales strategy, feature testing etc, but without a team that product isn't going anywhere.
2. A secondary meaning, "Further" means "Stamina". You + AI can create everything above, but without a community (whether paying customers or free users), the product dies when your interest in it dies, even if it is still making money!
(I admire PMs that can cross that chasm; it's also why they're often bad at infra tooling, because you can just short-circuit the empathy).
In my example (assuming a web view, but similar mechanisms exist for native), the event wrapper would give a lot of context if the event target string is logged. That will contain the query selector. It should already be best practice to have unique and human-readable IDs on every interactive element in the DOM anyway.
Sloppy frontend builds are a topic for another time, though.
If there's no server, you should at least still proxy these logs to your own domain. The vast majority of sites are just pasting a generated script tag or cluttering their build. The "right way" is just as easy.