r/AssetBuilders

I've been talking to recruiters and hiring managers for the past few months about technical hiring, and one thing keeps coming up.

Everyone screens the same way. Resume review, recruiter call, coding test, technical interview. Sometimes in that order, sometimes not. But almost always the same steps.
And almost everyone I talk to has hired someone who looked great through the whole process and then struggled in the first 90 days. Or passed on someone who probably would have been excellent because their resume didn't look right.
The tools haven't changed much. The problem hasn't changed much either.
I am currently building a solution for these issues.
Instead of a coding quiz, candidates go through a real work simulation and get scored across five dimensions instead of just one pass/fail. They do it once, and the profile is portable for future related roles, and there are other features as well.

I have a working prototype and I'm looking for recruiters and hiring managers who would be willing to spend 15 minutes to get a walk-through for validating it and sharing their thoughts.
If you have faced these issues as well and want to try how this new solution feels, comment below or send me a DM. Happy to find a time this week or next.

1. first ICP was a hypothesis. we then tested and validated relentlessly. speak to 100 ICPs to test your assumptions
2. add a high value on unprompted pain. when validating, don't let them know what you are building. ask disc questions and pain they bring up unprompted signals real pain
3. find a wedge. example: we build autonomous software QA so it would be easy to go "we test any software" but our wedge and ideal ICP is in the delta between AI speeding up their dev cycle, but can't afford bugs. a company not shipping quickly, or doesn't have critical revenue impacting bugs = no wedge for us. wedge = pain where you live
4. to reiterate, all the above is from intense validation. 
5. based on that. know what to cut, kill, double down on.
6. use the validation to understand the language of your ICP. do they say bugs or regressions? do they want to increase release velocity or ship faster? this language becomes your sales language
7. any hypothesis has to be tested
8. you have to build in the first instance on a bet/hunch. example, do all the above without building anything at all and you could build something not useful. build too much before this and you may have wasted time. make a bet, build minimum slither you can to showcase, validate, build.
9. convert the validation. if you validate with 100 potential ICPs, you now have an excuse to go back to them when you have MVP. "thanks for the validation. we've built around what you said. would love your view."
10. aim to convert those to design partnerships. partly building based on their feedback. this traction can be used to raise.
11. without becoming a dev shop
12. themes will appear from those partnerships. do all ecommerce companies need the same features? if you build a flow for a bank will other banks use this.
13. this data presents ICP paths you can once again test. example. we thought healthtech and fintech would be our markets: high regulatory risk = more need for a tool that prevents bugs. we didn't anticipate the flip side of that coin is also, it is difficult to build in regulated markets. higher expectations early on.
14. now you have data and social proof from design partnerships. wrap that up and find lookalike companies. why did it work well in those partnerships? what traits did they have. find similar. outreach using social proof.
15. Narrow ICP - we did it in sprints. every two weeks tested high volume across multiple channels into new ICP hypothesis. compared data. cut; scaled. explore vs exploit.
16. "would love your view on this" works surprisingly well if you solve an actual pain.
17. build faster than they expect. they will forgive fumbles if you move quickly and are solving a pain.
18. be honest about where you currently are but be v good at selling the vision of where you are going to get to.
19. network and events work extremely well in the early days. biggest barrier is building trust as pre-seed. much easier to do that face to face.
20. be shameless with outreach and favours
21. convert design partners to paid pilots once you launch publicly. 
22. be everywhere. marketing, posting etc. is long tailed. there is a trap of "we shouldn't start now it takes 12 months to see results" that's why you should start now.
23. measure everything.
24. have incredibly high standards; but keep velocity high
25. think of an objective. then double your targets, and half the time. you'll be surprised about what you can do

hopefully this is useful.

Vibecoding made building easy. Maintaining the product is the hard part.

Everyone talks about how AI lets you ship an MVP in a weekend.

What nobody talks about is what happens after deployment.

Users start churning.

Bugs show up in production.

Analytics tells you what happened but not why it happened.

You spend more time figuring out what to fix than actually shipping fixes.

I ran into this myself while building products. The MVP wasn't the bottleneck anymore. Understanding user behavior, finding issues before users left, and deciding what to build next was.

That's actually why I started building Tero.run

The idea is simple: connect your Git repo, monitor your product, get notified when things break, understand what users are struggling with, and ship improvements faster even from your phone.

Maybe the new challenge isn't building software anymore.

Maybe it's everything that comes after launch.

Anyone else feeling this?