r/Entrepreneur • u/FlatLiterature9702 • 9d ago
Lessons Learned The hardest part of building software isn't the coding
I've spent years building software and I've slowly realized that coding is often the easy part.
The difficult part is deciding what not to build.
You can spend weeks making something technically impressive that nobody actually needs.
The older I get, the more I think good product development is mostly saying "no" to interesting ideas.
Curious if other founders eventually came to the same conclusion.
51
u/mawktheone 9d ago
Id say the hard part is making cold calls and convincing someone to buy it off you
5
10
u/False-Egg-1386 9d ago
Yeah, I agree. Building is usually easier than choosing the right thing to build. A lot of good product work is just cutting scope and saying no early.
3
u/FlatLiterature9702 9d ago
Honestly, I’d put sales right up there with it. You can build exactly what people need, but convincing someone to actually pay for it is a whole different challenge.
4
u/betahaxorz 9d ago
I would agree for the most part, but this is very heavily dependant on what the product is. If it's some sort of CRM, then no. But if you were Larry and Sergey building Google, or one of the founders of Databricks, arguably coding was very much the hard part.
3
u/FlatLiterature9702 9d ago
Yeah, absolutely. There are products where the technical problem is the product itself. My point is more about typical SaaS, where it’s easy to spend months solving a problem that customers never cared enough about.
4
3
u/Falker_The 9d ago
As the founder of a bootstrapped and profitable SaaS: yes. The challenge is in determining what to build and what actually delivers value.
This is also why I laugh at those who think LLMs are going to destroy SaaS
3
u/vacantbay 9d ago
They may not destroy SaaS overall, but LLMs will definitely allow skilled individuals to exploit gaps or poor functionality in existing SaaS products. More competition, greater innovation.
0
1
u/FlatLiterature9702 9d ago
Exactly. Writing the code is becoming easier, but knowing what’s worth building, getting people to pay for it, and delivering real value is still the hard part. LLMs don’t remove that.
2
u/PlaybookPress 9d ago
Came to the same conclusion a while back. Building is the fun part, which makes it easy to confuse activity with progress. Saying no to shiny ideas is most of the job honestly.
1
u/FlatLiterature9702 9d ago
Exactly. Building feels productive because you can see things moving, but sometimes the most valuable thing you can do is just not build the thing.
2
u/Angalourne Aspiring Entrepreneur 9d ago
It depends on the scale of what you're building. Running solo or a small team, the hardest part is guarding scope. In large enterprise projects with multiple teams, the hardest part is without doubt driving shared understanding of that scope.
2
u/FlatLiterature9702 9d ago
Yeah, I think that’s the part people underestimate. Finding a real problem is one thing, but finding the right audience, reaching them, and getting them to trust you enough to pay is a completely different skill. You can sell mediocre software with great distribution.
1
u/AdeptVue Bootstrapper 1d ago
This right here is why I’m so hesitant to bring others on. I’ve done everything myself so far, but know I need to start reaching out to developers
2
u/Angalourne Aspiring Entrepreneur 1d ago
There are tried and true methodologies to accomplishing this. Make sure when you do bring on developers that they've had experience working on your tech stack at the target scale. Will save a ton of headaches later.
1
u/AdeptVue Bootstrapper 1d ago
I’ve debated between finding a tech co-founder(share a piece of the company) that has the experience to work on my current tech stack that would eventually hire their own team once revenue is there and reaching out to VCs to acquire the funding necessary to hire who is necessary without putting my trust in someone that says they can do it.
Having no one around close to me that is doing what I’m doing is definitely making these decisions difficult. Main reason I joined Reddit is to get 2nd, 3rd, & 4th opinions haha
2
u/Angalourne Aspiring Entrepreneur 1d ago
I run a software engineering department and can provide you some targeted advice. My tech stack experience is .NET, SQL, and React. The operational principles are fairly tech agnostic.
2
2
u/BusinessStrategist 9d ago
Someone has to bridge the gap between "Jobs To Be Done" and the "Product/Service Specification."
Do google "Jobs To Be Done" to get a "clear" picture of what a prospective buyer actually wants.
"Build it and they will come" is not a good idea mainly because you'll have to keep building and testing your product/service in the actual market.
A costly proposition unless you have money to burn.
Yes, there are many options for "getting on the same page" with an eager buyer.
1
u/FlatLiterature9702 9d ago
Totally agree. There’s a big gap between understanding what someone wants and translating that into the right product. Talking to customers early can save you months of building the wrong thing.
2
u/El_Loco_911 8d ago
Hardest part is sales. The rest is a joke. Selling enough to make a living is extremely hard. Making a well coded ap that works and does something useful is a piece of cake in comparison.
2
u/Ill-Check982 8d ago
Weeks is optimistic. The technically impressive thing nobody needs usually eats a year and a half and passes every internal demo with flying colours before someone finally asks who the customer was supposed to be.
2
u/bilal-cs 8d ago
Saying no to bad ideas is easy.. The hard part is saying no to good ideas that just aren’t the right ones/relevant right now. That’s where most of the wasted months come from!
1
u/FlatLiterature9702 8d ago
Yes true, good idea are hard to neglect.
1
u/bilal-cs 8d ago
Exactly.. What has helped me is keeping a NOT-NOW list. Every good idea goes there instead of straight into the build. If it’s still relevant a month later and someone’s actually asked for it, it gets built simply..
2
u/nictan93 8d ago
I think this gets harder when the feature request comes from someone ready to pay. Saying no means giving up an actual sale, especially when you need the revenue.
I'd look at whether other customers would use it and what ongoing support it creates. If it's specific to that buyer, quote it separately and include the maintenance involved. You can take the work if it makes sense, but don't price it like a small feature and end up supporting a custom system indefinitely.
1
u/I_am1221325 9d ago
I'd say the difficult part is to selling, like realizing not just what people need but is there a specific way to reach those people showing them exactly what they want and convincing them to pay. A lot of shitty software can be sold, if the audience and sales channels are good
0
9d ago
[removed] — view removed comment
1
u/FlatLiterature9702 9d ago
😂 Honestly, sometimes naming the damn thing takes longer than building it.
1
u/No-Molasses-2097 9d ago
The ideas that are hardest to say no to are usually the fun ones. What helped me was making every feature name the person who asked for it. If I was the only name on the list, it went into a doc and stayed there. Most of those ideas never found a second name.
1
u/BagAdministrative330 9d ago
Same conclusion from the other side of the table. The features that actually change a business are almost always the boring ones. The technically impressive demos usually gather dust. Meanwhile the dull stuff like automatic follow up reminders ends up paying for the whole subscription.
1
u/TheseBed8143 9d ago
A feature request gets more useful when you ask, 'What did you do the last time this happened?' The workaround can show how much the problem actually costs them. I'd want that answer before giving an idea weeks of work.
1
u/thepkizzle 9d ago
No, the hardest part is the business side and putting talent together. It is a nightmare. It is taking all my time up. Coding and what to code and what not to code and all that is easy. Finding people who you can reasonably do business with in coordination to build as a team that can function as a group of adults? That's the real work.
1
u/Particular-Intern-92 9d ago
Ya, particularly with how fast and easy it is now to build features. Adoption and utilization take far more time than building (always have actually, the difference is just magnified now).
So yes, it matters much more what you build and what you don't... because you gotta build things with a chance of adoption.
1
u/SmokeEast6255 8d ago
Pedantic, but deciding what not to build is the easy half. The hard part is deciding what to build, and the no's are just what falls out of that once you actually know.
1
u/Comfortable-Wave-395 8d ago
you can spend weeks something. dropped a word and still landed on the same take every founder has been posting for a decade.
1
u/Intelligent-Toe527 8d ago
god this one again. every founder who ever got a podcast has said this and it always comes from someone who already has people paying them. Saying no is easy when you have leverage, try saying no when you have 5 months of runway and the only guy willing to give you money wants a feature you personally find boring, you build it, you learn to like it, and shockingly it works. Slack came out of a failed game and nobody there was busy saying no to intresting ideas. The weeks making something impressive nobody needs thing is a phase everyone does at 24 and then never again.
1
u/OperationsJen 8d ago
The cheapest way I've found to kill a bad idea is to try to describe who'd use it and what they do today without it. If you can't name a real person and their current workaround, that's usually the sign. A week of talking to a few users beats a month of polished code.
1
u/mahee522 8d ago
Reached the same conclusion the hard way. I've burned weeks building stuff I thought was cool and then nobody cared. Coding is the fun part, so it's easy to hide there instead of doing the scary stuff like talking to users. Saying no to your own ideas is the actual job.
1
u/Icy_Zucchini377 8d ago
Small thing: deciding what not to build and deciding what to build aren't the same problem. You can turn down fifty interesting ideas and still have no idea what the thing actually is.
1
u/Icy_Zucchini377 8d ago
Small thing: deciding what not to build and deciding what to build aren't the same problem. You can turn down fifty interesting ideas and still have no idea what the thing actually is.
1
u/FounderInTheMaking 8d ago
100% agree. I'm still early and already caught myself adding features nobody asked for just because they were fun to build
what helped me a bit is writing down the one problem the product solves and checking every new idea against it. if it doesn't help with that one thing it goes on a "later" list. most of that list never comes back lol
urious how you decide though. do you talk to users first or just go with your gut after this many years?
1
u/CaesarB123 8d ago
Curious how you'd define that 'one problem', did you define it yourself or reached out to potential users / ICPs?
1
u/quiet_horizons1 8d ago
What helped me was treating every feature like a small business decision, not a coding decision. The test I use now is whether not having it is actually losing a sale or causing someone to leave. If it is only an interesting idea, it goes on a list that mostly never gets touched. Most requests are about a workaround or a one-off situation, and a quick conversation often shows the person can already do what they need with something that exists.
The other half is remembering that anything you ship becomes a permanent chore. You have to support it, document it, train people on it, and fix it later. Saying no to a feature is not just cutting scope, it is avoiding years of small obligations. Once I started thinking that way, the list of things worth building got very short.
1
u/Mistr_John_Alex 8d ago
I came to this from the other side. I build small systems for shops and service businesses, not software products. The rule that keeps me honest is that an idea only becomes a build item when a real user has asked for it in plain words, not when I think it would be clever. I keep a separate list called later. Most things die there, and that is healthy.
Saying no gets easier when you accept that a small tool that does its job well beats a big tool that half does several jobs. Every feature you add is also a support burden and a training burden. The owner may never thank you for the thing you did not build, but they will notice when the software stays simple enough to use without a manual. That restraint is the actual work, and it is harder than any screen I have written.
1
u/TheGrolar 8d ago
It's a whole job.
Engineers are the last people you ever want to put in charge of "what people need." Even if they're other engineers who purportedly have the same problem. I don't know how to address priority routing in a complex multi-service stack. Engineers don't know how to incorporate proximity-comfort threshold context into a product roadmap as an essential feature. How would I know about the handler requests? I never studied it. How would they know about semantic modeling? They never--but you get me.
1
1
u/Open_Professional71 8d ago
Yup, the hardest part is figuring out what people will actually pay for before spending weeks building it.
1
u/Kpow_636 8d ago
It's easy because of AI. I feel like you have forgotten how hard programming used to be when all you had was Google and stackoverflow, many many late nights debugging and trying to figure things out that required a lot of grit, persistence and starting over.
1
u/FlatLiterature9702 8d ago
Absolutely, and i miss the old days where i stay all night to build a complex solution and all the help i have is stackoverflow.
1
u/BernardoFTN_Carvalho 8d ago
The part that's hard isn't saying no, it's that you have to say it before you know anything. once people are using the thing it gets easy, you just wait until someone complains and build that. before that point every no is a guess too, same as every yes
1
1
1
u/ServeExtra9066 7d ago
If it's about building a business, then we can start from one of these: 1. Start with customer's problems. If they pay for the solution and we can build the solution, then there are chance that business could be built. 2. If you really obsessed about your software idea, then build MVP (minimum viable product) first, and launch it and update based on how users want it to be.
1
u/MarkoeM90 5d ago
Years in software and the big revelation is “don’t build useless shit.” Groundbreaking.
1
1
u/webstar_forever First-Time Founder 5d ago
But it's really hard to say no, especially being a young dev. I feel like, 'Oh, this idea is crazy, it must be.'
1
u/gagansgoraya 3d ago
100%. Writing the code is the fun, comfortable part because you're in total control of the outcome. Talking to the market and hearing that nobody actually cares about your brilliant technical architecture is the painful part. The best product development is almost entirely an exercise in discipline, saying no to cool ideas so you can focus ruthlessly on the one thing people are actually willing to pay to fix.
1
u/PeaceOfZen 3d ago edited 3d ago
I agree. People are always chasing the new shiny object. It doesn't have to be flashy .Just has to solve a problem that others have that they're willing to pay for a solution to
1
u/sure_shot99 3d ago
I have built 2 products of which the successful one is the least time I spent building. Other is simply staying idle on my laptop. But the idea that succeeded came after building the failed product. I hope you got what I'm saying.
1
u/PatientlyRelentless 3d ago
The more technical you are, the more you delay the uncomfortable part of selling. You always see a gap somewhere - not necessarily a feature, but an improvement. “When i fix x then i’ll start shipping” - getting stuck in this loop is easy as you still have to-do’s and delay the launch/shipping
1
u/alexrichbuilds 1d ago
I genuinely think this has changed. With AI, now anyone can rebuild everything and so the value of building something small or focused is lost in the world of slop and other attempts to get rich quick.
1
u/AdeptVue Bootstrapper 1d ago
When does everyone decide to start bringing on employees to manage their code base?
0
u/AlexeyAnshakov 9d ago
The hardest part is resisting the urge to write software before you have verified the operational workflow by hand.
Most software projects fail not because the code was buggy, but because the founders automated a completely imaginary business process.
If you haven't manually solved the customer's problem 50 times in a messy Google Sheet or over email, you have no idea where the edge cases and human friction actually live. You will end up writing 10,000 lines of pristine code for an idealized workflow that nobody in the real world actually uses.
Code is the easy part. Codifying real human operations into deterministic logic without breaking edge cases is the real job.
1
u/FlatLiterature9702 9d ago
This is a really good point. There’s a big difference between automating a workflow and actually understanding the workflow first. A spreadsheet and some manual work will expose problems that a perfectly designed system never will.
0
•
u/AutoModerator 9d ago
Welcome to /r/Entrepreneur and thank you for the post, /u/FlatLiterature9702! Please make sure you read our community rules before participating here. As a quick refresher:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.