For the first year of our startup, it was just me and two co-founders writing code. We finally raised a small pre-seed round and decided to make our first big hire: a Senior Software Engineer.
We were thrilled when we snagged someone from a major tech company (think Google/Meta). On paper, they were a rockstar. The resume was flawless, they passed our technical interview easily, and we paid a premium salary to get them.
The shoutouts on Product Hunt allow makers to list the tools that they used to make their launch possible, and the Top Product tags make use of this information, together with reviews. At some point I caught myself using this as a way to choose a database or hosting provider, and I am not sure that this is a good thing.
The positive aspect is obvious: a tool that is frequently mentioned by working makers has probably been through a lot of deadlines. Knowing what builders are listing Supabase or Vercel gives me more insight than reading the feature list ever could.
Last month we checked our internal collection of prompt examples and found instructions going past two thousand words. We thought more details meant results but our tests showed the opposite effect.
When directions get long models start missing important formatting rules hidden in the middle sections. Our output became more consistent only after we made those big sections shorter and used bullet points instead.
We learned to see prompts as code functions not as assignments. Keep the focus small explain input values clearly. Take out all the friendly conversation words.
A short instruction set makes the model use its knowledge instead of getting lost in different style rules. Fewer words often mean thinking.
As I work toward getting more people to use my product I've been building.
We spend so much time testing whether our software works. We check functionality, fix bugs, improve the interface, and make sure everything behaves as expected.
But I've started questioning whether we're always testing with the right people.
I'm building a consumer app, and I've read plenty of advice on what should work. I'd rather hear what did.
Here's where we are, to start honestly: paid ads on Meta bring installs but are expensive for a small team. SEO started paying off only this month, the surprise was that the first clicks came from translated pages (Ukraine, India, Poland), not from English. Store search brings a steady trickle. Nothing yet that I'd call a channel.
Some software is naturally transactional people use it on Friday month ends, or during specific project sprints. But then they churn because they didn't get enough daily value.
If your product isn't a daily-active messaging or project board tool trying to force daily usage feels unnatural and forced. Yet, investors and metric dashboards always push for higher engagement frequency.
If your product isn't meant to be opened every single day, how do you engineer sticky loops or meaningful checkpoints so users don't forget you exist between use cases?
December is the month that officially closes the launch chapter of the year, so you still have a last chance to come up with something that will get attention.
Such December classics are definitely products with these narratives:
Wrap-ups
Advent Calendars
Most searched topics
Prognosis for the coming year
Productivity and health apps (ready for New Year's resolutions)
You can have the cleanest codebase in the world, but if a developer has to scroll past three paragraphs of fluff just to find the quickstart command, the repo is getting closed. The last few repos I starred all had one thing in common: I could copy-paste the install command and see it running locally in under sixty seconds. Beyond that it's all about trust in the maintainer.
Have you ever un-starred a project because the repo went completely silent after a big launch?
