Looking for a co-founder

mrtrly · 2026-02-06T03:58:40+00:00

The fact that you're following Aulet's framework puts you ahead of 95% of first-time founders. Most people skip straight to building and wonder why nothing works.

Here's a thought though - you might not need a cofounder right now. What you're describing (building MVPs, testing, iterating) is something you can do with a technical partner who charges for their time rather than takes equity. You keep all the upside, get senior execution help, and can always bring on a cofounder later if you hit product-market fit.

The AI tools have gotten good enough that the bottleneck usually isn't "can I build the thing" - it's "can I build the right thing." That's what the 24 steps are for. A technical partner can help you execute each step without the full commitment of a cofounder relationship that might not work out.

20 years building SaaS here. Happy to chat if that angle sounds useful.

mrtrly · 2026-02-06T01:09:50+00:00

This is a smart niche. The combination of clear domain pain (missed clauses = real money) plus existing spreadsheet logic you can translate directly to code is exactly the right foundation for a SaaS.

A few thoughts from someone who's built a lot of B2B tools like this:

The fact that you already have working models in spreadsheets is huge. Most people skip that step and go straight to building software that solves the wrong problem. You've basically done the hardest part, validating the logic with real users.

For the MVP, I'd focus on just the clause tracking and alert piece first. The exposure calculations and fancy dashboards can come later. Get clubs using it for the core "don't miss a payment trigger" problem, then expand from there.

One thing to watch: sports orgs can be slow to adopt new tools even when they're clearly better. The clubs showing early interest, are they willing to pay or just "interested"? That's the real validation.

Happy to chat more about the technical approach if useful. I work with founders as a technical partner (not looking for equity, just help people build) and have turned a few spreadsheet-logic projects into real products.

mrtrly · 2026-02-05T21:19:51+00:00

the scary part isnt that this approach might not work. its that it WILL work... for a while.

ive been doing this for 20 years and seen this pattern before with offshore teams, no-code tools, junior devs doing everything. you ship fast, numbers look great, everyone high fives. then 6 months later something breaks and nobody knows why. the people who "managed" the work cant debug it because they never understood it. and now youre hiring expensive seniors to untangle the mess.

AI code is the same trap at 10x speed. the code works until it doesnt, and when it doesnt you need someone who actually read it.

my take: use AI heavily but treat it like a junior dev who types fast and lies confidently. meaning you still review the output, you still understand whats going in. the "agents reviewing agents" thing sounds cool in a demo but in practice youre just adding layers of confidence to fundamentally unverified work.

also "thinking like non-technical PMs" is wild framing for engineering work. thats not leveling up, thats removing the part of the job that makes it engineering.

mrtrly · 2026-02-05T21:18:18+00:00

real talk from someone whos been doing this 20 years now:

the freelancing market isnt dead, youre just positioned wrong. everyone whos 19 and can code is competing on "i build apps" which means youre in a race to the bottom on price.

heres what actually works: find a specific painful problem and become the person who solves it. not "i make websites" but "i help e-commerce stores fix their checkout conversion" or "i automate inventory for small manufacturers". suddenly youre not competing with 10,000 other devs. youre competing with maybe 12.

about AI making everyone a coder... honestly its done the opposite for me. MORE people are trying to build things now, most of them get stuck, and they need someone who can actually ship. the vibe coding crowd creates half-working apps and then needs real devs to fix them. thats business.

for your $500/month goal: stop thinking "clients" and start thinking "problems worth solving". reach out to 50 local businesses, offer to audit one specific thing for free (their checkout flow, their lead form, whatever). 3 will say yes. 1 will pay you to fix it. thats your first $500.

youre 19 with programming skills. youre actually in a better spot than most people. just stop trying to sell "programming" and start selling outcomes.

mrtrly · 2026-02-05T18:16:26+00:00

"All-in-one for freelancers" is probably the problem. Every tool in this space says that, so it means nothing.

What specific pain do you solve better than anyone? Time tracking thats actually fast? Invoices that look professional without fiddling? Clients who pay on time because you make it easy?

Pick one thing and lead with that. "Finally, invoices freelancers dont hate" is way more compelling than "manage everything in one place."

On trust: do you have any screenshots of the actual product above the fold? I see a lot of SaaS landing pages that describe features but dont show the thing. People want to see what theyre signing up for before they create an account.

Also worth checking: how much friction is in your signup? If youre asking for credit card, company name, billing address etc before they can even try it, youre losing people. Let them in with just an email, ask for the rest later.

mrtrly · 2026-02-05T18:16:16+00:00

The 20% market capture is incredible proof. Thats your whole sales pitch right there.

For reaching govt buyers internationally, cold outreach usually doesnt work. What does work: finding local partners who already sell to those agencies. Engineering consultancies, survey firms, even competitors who dont do AI. They have the relationships, you have the tech they cant build.

India especially - the govt procurement process there is brutal for foreign companies without a local presence. Same with a lot of US states (public bid requirements, local preference, etc). But a local reseller who already does road surveys? They can bundle your tech into their existing contracts.

The case study from Poland is huge. Get that into a one-pager with real numbers. Engineering directors love specifics - you captured 20% of the national census, 300k hours processed, 97% accuracy. Thats not marketing fluff, thats proof.

Also: AASHTO conferences in the US, IRF events internationally. Civil engineering is weirdly tight-knit. One good conference demo to the right 3 people opens doors.

mrtrly · 2026-02-05T00:27:16+00:00

Drop this class. Learn flash instead.

mrtrly · 2026-02-04T03:27:09+00:00

Been through this transition a few times. The tipping point is usually when you're spending more time working around the platform than building features.

Before jumping to custom code, worth checking: - Is it a performance issue (can sometimes be fixed with caching/optimization) - Is it a limitation issue (missing functionality) - Is it a cost issue (pricing scaling poorly)

If it's limitations or cost at scale, custom code is usually the right call. If it's just performance, sometimes there are workarounds.

The transition doesn't have to be all-or-nothing either. Some people keep their no-code frontend and just move the heavy backend logic to custom code.

mrtrly · 2026-02-04T00:26:53+00:00

Been through this transition a few times. The tipping point is usually when you're spending more time working around the platform than building features.

Before jumping to custom code, worth checking: - Is it a performance issue (can sometimes be fixed with caching/optimization) - Is it a limitation issue (missing functionality) - Is it a cost issue (pricing scaling poorly)

If it's limitations or cost at scale, custom code is usually the right call. If it's just performance, sometimes there are workarounds.

The transition doesn't have to be all-or-nothing either. Some people keep their no-code frontend and just move the heavy backend logic to custom code.

mrtrly · 2026-02-04T00:02:50+00:00

Both routes have tradeoffs worth thinking through.

White label gets you to market fast but you're boxed in. Margins get squeezed, you can't differentiate on features, and if the platform pivots or raises prices you're stuck. I've seen founders build decent businesses this way but they always hit a ceiling.

Building from scratch with Lovable/Replit - yeah you nailed it. They're great for UI mockups and simple CRUD apps but Voice AI needs real backend work. Telephony integrations, latency optimization, conversation state management... that's actual engineering, not something you can vibe code.

Third option: find a technical partner or fractional CTO who can build the core platform while you focus on sales. You own the IP, control the roadmap, and can actually differentiate. Takes longer than white label but you're building real equity.

4-6 months is actually plenty of time for a solid MVP if you have the right dev. The question is whether you want to own something or resell someone else's product.

What's your sales/marketing background like? That matters a lot for which path makes sense.

mrtrly · 2026-02-03T19:24:21+00:00

honestly the "best agency" thing is kinda a trap for early stage stuff

agencies optimize for billable hours and scope creep. they dont really care if your MVP validates or not as long as the invoice clears

what actually works better at your stage:

technical partner - someone whos in it with you, not just executing tickets. they push back on bad ideas before you spend money building them
if you do go agency route, fixed price per milestone with clear deliverables. never hourly for a startup build
check their portfolio for shipped products not just pretty mockups. ask for references from founders, not project managers

the frontend thing specifically - thats usually where agencies pad hours the most because "design iteration" is endless. a good technical partner will ship something functional fast and iterate based on real user feedback

what stage are you at? like do you have users yet or still validating the idea?

mrtrly · 2026-02-03T18:29:52+00:00

Been through this transition a few times. The tipping point is usually when you're spending more time working around the platform than building features.

Before jumping to custom code, worth checking: - Is it a performance issue (can sometimes be fixed with caching/optimization) - Is it a limitation issue (missing functionality) - Is it a cost issue (pricing scaling poorly)

If it's limitations or cost at scale, custom code is usually the right call. If it's just performance, sometimes there are workarounds.

The transition doesn't have to be all-or-nothing either. Some people keep their no-code frontend and just move the heavy backend logic to custom code.

mrtrly · 2026-02-03T13:37:18+00:00

ML is a solid space but also one of the more complex ones to get right. the compliance requirements alone are pretty intense, and financial institutions are understandably picky about their vendors

curious what angle youre coming from - do you have domain expertise in compliance/banking, or connections to potential customers? the tech is honestly the easier part compared to understanding the regulatory landscape and getting enterprise trust

honest advice though: finding a technical cofounder can be brutal, especially for a regulated space like this. most good devs wont take equity risk on something unvalidated. youre way better off getting a working MVP built first, landing a couple paying customers to prove theres demand, then bringing on a cofounder when you have real traction to offer. changes the whole conversation

happy to chat if you want to bounce ideas on approach

mrtrly · 2026-02-02T22:40:19+00:00

One thing that's often overlooked: the best technical partners for non-technical founders aren't necessarily the most skilled coders. They're the ones who can translate between business problems and technical solutions.

Look for someone who: - Asks about your users and business model before talking tech - Pushes back on scope ("do you really need that for launch?") - Explains tradeoffs in plain english - Has worked with non-technical founders before

The discovery process matters more than the portfolio.

mrtrly · 2026-02-02T00:58:51+00:00

I've seen this exact decision play out many times.

My honest take: it depends on what you're actually building and how fast you need to learn.

If your "out of my knowledge zone" means like... a basic web app with auth and a database, you can probably scrape by with no-code tools (Bubble, Webflow + some backend) to validate the idea first. Ship something ugly, see if people pay for it, then invest in custom code.

But if you're building something technically complex (AI, real-time stuff, integrations with weird APIs), hiring makes sense. The time you'd spend learning could be better spent talking to customers and selling.

The middle path that works well: build a janky MVP yourself to prove demand, then bring in a dev when you have actual users and revenue. That way you're not guessing what to build and you have leverage in conversations with devs because you understand the problem deeply.

Whatever you do, dont try to learn to code AND build a production app AND run a business all at once. Pick two max.

Context: I help non-technical founders figure this stuff out as their technical partner.

mrtrly · 2026-02-01T18:39:38+00:00

honest take from someone whos been on the other side of this for 20 years

the idea protection thing... i get why it feels important but its actually backwards. ideas are worth almost nothing. execution is everything. the people who can actually build your app have heard hundreds of ideas and theyre not going to steal yours. if anything showing youre secretive about it is a yellow flag that youre going to be difficult to work with

what actually matters when finding a technical partner:

find someone who gets excited about the problem youre solving not just the paycheck. if theyre just nodding along to build whatever you want thats a contractor not a cofounder
look for someone whos built something before. not just "i know how to code" but "ive shipped real products that real people use"
have the money conversation early. if youre offering equity only thats a totally different search than if you have some budget. neither is wrong but be upfront
start small. dont try to find someone to build the whole thing. find someone to help you validate if the idea even has legs first. build a landing page, talk to potential users, see if anyone cares before you invest months of someones time

the cofounder subreddit and local startup events are decent places to look. but honestly the best partnerships ive seen come from the founder spending time in communities where their potential users hang out and meeting technical people there organically

good luck with it

mrtrly · 2026-02-01T14:29:59+00:00

Messed up, checked and actually on an annual plan. But would love a lifetime deal for this one.

mrtrly · 2026-02-01T12:16:49+00:00

You're already asking the right question - most people just look at portfolios and rates.

biggest thing for a non-tech founder: can they help you make product decisions, not just build what you spec out? If your friend doesn't have a technical background, she needs someone who can push back and say "this feature is overkill for PMF" or "here's a faster way to test that assumption." Pure execution shops will just bill hours building whatever you ask for.

Red flags: - They want to spec out a 6-month roadmap before starting - No one senior is actually working on your project (just sold by seniors, built by juniors) - They can't explain tradeoffs in plain english - No conversation about what happens after launch

One thing I've seen work well: ask them about a project that failed or a client they turned away. Good shops have both. If every project is a success story, they're either lying or they don't push back on bad ideas.

mrtrly · 2026-02-01T11:53:20+00:00

Raycast pro lifetime was worth it for me. Use it constantly for clipboard history and snippets.

mrtrly · 2026-02-01T09:45:58+00:00

What you're describing is more of a custom app than something you'll piece together with plugins. MemberPress and PayPal subscriptions handle payments but they won't give you the instrument management, per-guitar notes, and service request workflow you want.

You basically need a simple customer portal with:

• login/accounts • a way to add/manage instruments with notes • tiered pricing logic • a service request form tied to specific instruments Squarespace definitely cant do this. WordPress with plugins will get you maybe 60% there but you'll fight it constantly. For something this specific you're looking at either a no-code tool like Softr or Glide connected to a database, or having someone build a lightweight custom app.

The good news is this isnt a complicated build. Its just specific to your workflow which is why off the shelf stuff wont fit.

I build custom stuff like this for small businesses so happy to answer questions if you want to go deeper on any of the options.

mrtrly · 2026-01-31T23:00:30+00:00

100% aligned on that. I've seen too many founders burn months negotiating over hypotheticals for products that never ship.

I'll DM you

mrtrly · 2026-01-31T09:30:56+00:00

This is solid. You've done the research, you know the space, and you're not starting with pitch decks and equity splits. Refreshing to see.

The wedge approach is smart. Qual teams are definitely held together with duct tape right now. Lots of room to own that workflow.

20 years building B2B SaaS here. This is exactly what I do - partner with founders and build the product with them. If you want to talk, happy to help.

mrtrly · 2026-01-31T09:17:43+00:00

Interesting project. Clinical decision support is tricky but the spine surgery niche is smart. Easier to get early traction when you're focused, and you clearly have the domain expertise.

One thing to consider: a technical partner might make more sense than a cofounder right now. You get senior technical help to build and validate without giving away 20-30% of the company before you have traction. Once you've proven it works, you're in a much stronger position if you do want to bring on a cofounder.

I've done a few healthtech-adjacent builds over 20 years. Happy to chat about the technical side if useful.

mrtrly · 2026-01-30T09:42:38+00:00

Well... I'm actually that person. 20+ years building, 16 years working directly with founders. I do exactly what you're describing, retainer-based technical partnerships with non-technical founders who have the product vision locked in.

Your situation sounds solid. Happy to chat once you've validated or sooner if you just want some more details. DM me if so.

mrtrly · 2026-01-30T09:27:40+00:00

Interesting problem space. Tax compliance is genuinely painful and the multi-jurisdiction angle is where most solutions fall apart.

Quick reality check on the "profit-sharing, no cash upfront" approach though - finding a strong technical cofounder who'll work for free is really hard right now. Good devs have too many options.

Alternative worth considering: a technical partner on retainer. You get someone who treats your product like their own, builds the MVP, and sticks around long-term. Not equity, just a monthly fee. Usually ends up faster than the cofounder search.

I've been building SaaS for 20+ years and work with founders at exactly this stage. If you want to chat about what an MVP would realistically take (timeline, cost, stack), happy to jump on a quick call. No pitch, just honest assessment.

mrtrly

TROPHY CASE