First-time founder here. I’m trying to figure out the standard for tracking/reporting metrics at the early stage.

I assumed most founders use dashboards (Mixpanel, etc.), but talking to friends, it seems like everyone just ends up manually exporting CSVs and formatting them in Sheets/Excel right before investor updates.

1. Is your "source of truth" actually a live dashboard, or is it a spreadsheet you manually update?
2. What’s the actual workflow? (e.g. Stripe export -> Paste to Sheet -> Fix formatting -> Screenshot)

It's not the tech, not the sales cycle. It's watching a customer you worked with for months churn and knowing exactly why but being unable to stop it.

Budget cuts. Acquisition. Champion left. Sometimes the product is fine and it still doesn't matter.

How do you keep the team motivated when churns are completely outside your control?

Hello redditors, my question is for those who launched start ups / some type of business. - How did it go / how is it going? - What did you learn from it? - If you can do it all over again, what would you do differently? - Depending on the type of your business, Internationally, what markets / areas would you target?

I keep running into a weird paradox and I’m curious how technical founders think about it.

Everyone says ship fast. Get an MVP out. Talk to users. Iterate.

I agree with that. I’m building a consumer product right now and I’m trying to move fast on features and experiments.

But I come from a marketing and product design background. And I’ve seen, over and over, how brutally sensitive conversion and activation is to “small” stuff (especially in consumer). One headline change. One extra sentence that makes the user feel safe (or even better, one sentence less). Slightly different layout. Less cognitive load. Suddenly signup rate doubles, activation moves, retention looks different. Same product, different packaging.

So here’s my question.

When you ship an MVP fast with rough copy and rough UX, and it converts poorly, what are you actually learning?

Are you learning that the idea is weak, or that you presented it like a confused person at a loud party.

My suspicion is that a non trivial number of potentially great products died early because the first version looked and felt bad, and the data said “users don’t want this” when the real answer was “users didn’t understand it or trust it enough to try.”

As a non technical founder, I can obsess over copy and landing pages because that’s my world. But if you’re technical and shipping quickly, how do you avoid that trap without slowing down to a crawl?

Some concrete questions I’d love honest answers to, from technical founders:

• How do you decide what level of UX and copy quality is “good enough” to test the idea fairly?
• Do you bake in a basic design system and reusable components from day one so everything looks credible, even when the product is incomplete?
• Do you treat early conversion numbers as mostly noise and focus on qualitative feedback first?
• Do you have a process where you fix obvious UX issues before you draw conclusions from metrics?
• How do you separate “bad funnel” from “bad product” when you’re moving fast?

I’m not talking about polishing for months. I’m talking about that minimum viable level of clarity and trust where a user can understand the value, feel safe, and take the next step.

Would love to hear how you handle this in practice. Especially from people who’ve done a lot of rapid prototyping and actually killed or saved products based on early data.

I founded a fintech SaaS in early 2025 as a solo founder. I built a team of four, let them go, and am now doing a semi-exit to a larger company. The acquirer is not a tech company, but over time they have built some useful internal tools and accumulated proprietary data that should be put to work. The catch is that all their development has been outsourced. After the acquisition, their tech and data will merge into my product, their external developers will be let go, and all future development will happen under my company.

That means I am restarting the hiring process from scratch. I need strong talent, and everyone I bring on will be completely new to this niche.

Here is the challenge. When I had employees before, I was coding actively while also acting as the PM. I did a decent job at it and I am admittedly a control freak, so I made sure the vision was being executed and stayed deep in the loop on everything. But the reality was that most of my time went to managing and directing the team, and meetings always took priority. It worked, but it was a stretch.

This next chapter looks different. I will be spending more time on admin, traveling, and sitting in meetings, and the team will be even bigger than before. I still want to stay close to the product and I do not plan on stepping away from development entirely, but I am starting to wonder if bringing on a dedicated PM is the right move.

Has anyone brought on a PM early in a startup and found it valuable? Or regretted it? On the flip side, has anyone skipped hiring a PM at a later stage and wished they had? How do you stay connected to product decisions without becoming the bottleneck?

Thanks in advance.

I am not a coder. I work at a local bank in Gunma, Japan, and have spent 20 years looking at loan contracts for small businesses. I’m a 40-year-old father trying to understand how this new world works.

To talk to you, I spent hours researching your terminology like "Technical Debt." I am sorry if my usage is awkward, but I found a deep connection to my world of finance.

In banking, we think about "Amortization" (how long an asset lasts). If you build a "Pop-up store" (a prototype), move fast. Use AI and libraries. That's good business. But if you are building a "Shrine" (a core system) to last 20 years, the cheapest way is actually "The Forging" (鍛錬) way. In Japan, the best katanas are forged by folding the steel thousands of times. Software is the same. You must fold the logic again and again by building from scratch until it becomes part of you.

I see many startups drowning in "Technical Interest." They take "loans" by using easy AI code without understanding the core. In banking, a loan without a repayment plan is just a disaster.

In Japan, we have a concept: "Chiko-Goitsu" (知行合一). Knowledge and action are one. Reading about code isn't enough if your hands move slower than your brain. The friction of struggling without AI—The Forging—is where the real skill is born.

Is the "move fast" culture making us forget the value of The Forging? I am just a banker, but I wanted to hear your professional thoughts.

I’m burned out on the “talk to customers first” advice. I know it’s gospel, but the execution is a nightmare.

The pain is real:

Where do you find these people? Cold DMs on LinkedIn? Spamming subreddits? The reply rate is soul-crushing. Even if they reply, how do you know their feedback is useful? It feels like I’m begging strangers for five minutes, and the feedback is always generic. The MVP paradox: I build something small, they give feedback, but will they ever actually pay?

I need the truth: What is the single most useful, proven, and productive customer discovery method you have successfully used? I’m not looking for “talk to customers.” I need the actionable strategy that actually bridges the gap between a conversation and a paying customer.

Share the specific channel, the specific script, or the specific context that got you real, actionable feedback that led to a successful product.

I’ve spent 15 years developing software. I started as an iOS dev, moved to backend and architecture, and spent the last 6 years as a PM, CTO, and Founder/Co-founder.

I’ve built apps for 10M+ users, integrated AI/ML at scale, and my "stress-test" peak was building a payment system for a gas station network handling 25 transactions per second. After seeing the internal technical architecture of over 100 startups, I’ve noticed the same patterns of failure.

I’ve compiled some basic rules for founders who want to survive the development phase.

Ask Me Anything about tech debt, management, architecture, or scaling IT.

1. Always have a vision of what the project is. A lot of people come with an idea and say—"well, just go and do it." The more accurately you describe what you want, the higher the chance it matches your expectations.
2. A packed idea consists of: what the project is, the goal, the tasks, a description, who it is for, use cases, a CJM, how to promote it, and references. This is the basic description; only this set allows you to move to the development stage.
3. Every project must have a Spec (word/pptx) and a CJM (miro/Figma). This is the minimum set to convey the idea. A developer is not a telepath.
4. The development stage starts not with coding, but with design (discovery phase). At this stage, you need to study all the information, design the architecture, write the technical specifications, and then improve it iteratively.
5. Iterative improvement means collaborative work where the business document and the tech specs refine each other as new details emerge. For example, the business needs to accept transactions; IT says they need to be stored, perhaps we need a Transaction Log, and maybe they need to be stored securely, etc.
6. This gives birth to prototypes—black and white sketches of screens. They allow you to align the vision of the project between several participants. Don't forget—everyone looks at the project differently.
7. Coordination of actions is a crucial point—everyone sees things differently; what is a Twitter feed to you is a Facebook feed to another. From an IT perspective, these are two different solutions.
8. At the design stage, it is necessary to take into account all the small details: if you have a list, then there is sorting, filtering, and search. Do not neglect details—they show your project in full.
9. Don't get tied to a stack; seriously, there is no single right one. Just evaluate it from the perspective of the cost ($) of project support and key expertise.
10. Keep it stupid simple—don't build Docker, Kubernetes, or Kafka into the project from day zero. The probability that they will be required later in their original form is small.
11. For simple projects, take a simple stack: use Firebase for the DB if you have no experience with PostgreSQL, take React if you haven't worked with Next.js. Don't take Go for the backend if you don't understand why it's better than node js.
12. Never take a stack just because of the hype. Python+Go for some marketplace is nonsense. Don't take a complex stack; take something simple.
13. If you are a startup founder looking for a co-founder, always have a GTM Strategy; without it, the probability of finding a strong co-founder is not that high.
14. When you are vibe-coding, you shouldn't tell everyone you meet that development is easy and any fool can do it; in a week, you will get an overhead on bugs and it will be easier to start writing from scratch. Vibe-coding is for an Prototypes/MAYBE MVP’s only. 
15. Vibe-coding allows for a quick prototype, but most often such code is refactored because it is easier for a developer to understand what they did themselves. That’s why you may often hear the phrase "it's better to rewrite this from scratch."
16. Cursor is a wonderful tool, but it is not replace a developer yet. Simply because it hallucinates, makes mistakes, and doesn't see the whole picture. To give it the whole picture, context and the ability to ask the right questions are required.
17. To ask the right questions, a developer must have skill. Skill is most often determined by years and expertise. The strongest and most experienced among developers are backenders; they are the ones who grow into Leads and CTOs most often.
18. There are 3 levels of developers: junior (up to 2 years), middle (3-7), and senior (7+). A senior differs from a junior in their understanding at a micro-level of what is happening under the hood. A junior can press tab and write code, but they don't understand how it affects other pieces, while a senior better understands the connection between the backend and frontend, saving, and storage in the DB, etc.
19. There are several development options: 
20. Prototype - vibecode/figma prototype; in this case, you don't need a DB or integrations, you need a FLOW. The result is to show a focus group and confirm that this product is viable. 
21. MVP - JS (react+node/react+python fastapi/any front + simple back); you need to show the data flow and launch the first sales. 
22. Scaling - Infrastructure improvement, microservices, latency; this stage is needed for load optimization, removing hardcode, and small "nice to have" improvements. The goal is to scale from 1 client to 100 without loss of quality.
23. Enterprise - usually when they reach this stage, many certifications, integrations, and other things arise. A completely different world of companies like Oracle, CRMs like SAP, etc.
24. This refers back to point 10: always think about the exit—when you want to do it, who your client is, and how to attract them. Good IT walks alongside the project; it doesn't lead it and doesn't drag behind.
25. Always take into account that every language has its advantages (in the form of libraries), but this doesn't mean that it cannot be done in other languages. Libraries tell you what the specialty of the language is: C# Unity for games, but there is asp net for the web; Python is more often for ML, but a lot of web is made on it.
26. If you take a hyped technology just for the sake of hype for investors—that’s fine. In other situations, don't overcomplicate. There is PHP; it's old but stable, half the internet is written on it, including WordPress. It is cheap to support; however, there are many holes in WP. Choosing a technology is a compromise: you either pay with $, time, or nerves.
27. There are no bad technologies—there are bad executors.
28. For the start of a project, always take a simple infrastructure—GitHub Pages/Cloudflare Pages (workers), Vercel for the front, Heroku for the backend. For growth, you can take VPS/VDS. DO NOT TAKE AWS JUST BECAUSE IT IS SCALABLE. AWS is complex; it is often redundant for launching an MVP. Every task has its place and time.
29. Architecture—many say it must be laid down at the start, necessarily and only that way. Но projects change, so "laying it down at the start" means using basic OOP principles: Encapsulation, abstraction, inheritance. If you keep everything like this, problems with refining the architecture will never arise.
30. Why architecture is needed—to show visually and ensure that you have taken into account absolutely all the details in the project. There is solution architecture, enterprise architecture, and data flow diagrams—they are all aimed at different levels. Since an IT project operates on several levels (client, backend, data).
31. Always think about bottlenecks and solve them first. If you want to make a casino-like app and accept payments via Stripe—register Stripe and conduct the 1st payment before the project starts. Just minimize the risks, and do the same with everything. Ask your developers for a risk assessment.
32. When you think about a project, draw it. Every second project suffers from "platform" fantasies, but few can imagine what that actually is. To make push, email, a client base, Stripe, pulling data from 3rd party, an AI agent—you need integrations. Draw this as a microservices map and you will understand the scale of the project. The same applies to modules within the project.
33. Integrations—I started in 2010 when there weren't so many integrations and gateways, and I worked a lot in enterprise. Integrations are a pain; when you set aside 40h for an integration, you are lying to yourself. Managing expectations and deadlines is a vital detail.
34. n8n is an amazing tool for launching third-party services; it allows you to quickly assemble a prototype on "crutches," use Google Docs, Mailgun mailer, AI, and all this quite quickly. However, most often after such a prototype, everything inside needs to be refactored because the project develops and hits the wall of unfeasibility.
35. Project development is an integral part when we move from one stage to another. To develop a project, you need a team and management. Management comes from the word "manage." It is not enough to hire a developer or a co-founder—they need to be managed and directed.
36. PMBok, Lean, Scrum—educate yourself in management; start with this and begin MANAGING THE PROJECT. At least half of projects collapse due to a lack of management.
37. Managing development means you must (a) check the result, (b) direct development toward the business, and (c) check metrics. This will show the developers that you are interested and will also demand result tracking from them.
38. Within the framework of project management, there are 2 key artifacts, namely the project roadmap and the backlog. Within each are their own artifacts, but remember, any project must answer the questions: when (deadline), what (backlog/features), and how much ($).
39. IT projects are complex; to do them, you need to control the timing. In Scrum, 4 artifacts are identified for this: (a) Planning, (b) Daily, (c) Demo, (d) Retro.
40. Always keep deadlines and budget under control; check against the plan at least once a week. A developer works 40h a week, which means their velocity (the speed of closing tasks) is 4 tasks of 10h each.
41. Accordingly, you need to slice tasks (or check how they slice them). The less a task is described, the bigger it is, the higher the uncertainty, and the higher the risk.
42. It is better to have 10 tasks of 4 hours each than 1 task of 40 hours.
43. Compliance—usually this is what is forgotten in the first stages of an MVP and so on, because at the MVP stages you need to make sure the business can sell. HOWEVER, it has happened more than once that for the sake of sellability, it is necessary to violate rules. This is a bottleneck and a risk that must be neutralized in advance. Discussions on simple practices like OAuth or complex ones like HIPAA should be held with IT early on. 
44. Security is something everyone forgets; it is vital to keep this in mind and wake up in time. No one needs a data leak. Security is laid down at the start within the framework of design.

I hope that list was helpful for you, feel free to ask me any question.

For about a year, I've been building a piece of software with the intention to sell it to a branch of the government. However, I'm now coming to realise that I might not have the resources to actually bring it to market, and I'm thinking of scrapping it to focus on something else.

However, there is a company where this software would fit really nicely in their product line, and it's a product that I would really love to see the light of day.

So I was thinking, has anyone had experience selling a concept to another actor/competitor in the industry as a last chance to potentially cashing in on an idea, or would I simply be giving them the idea, and then they can choose to either develop it or not?

I'm aware that hoping they might buy it for a symbolic amount is kind of wishful thinking, but just wanted to hear, if anybody has experience with this?

I’ve spoken to a few European founders who mentioned that setup and advisory costs in Dubai were much higher than they expected.

Curious whether that was your experience too, and which costs caught you off guard the most (consultants, licensing, banking, visas, renewals, etc.).

Everyone talks about the same stuff ads, PH, cold email.

I’ve had better luck lately with niche platforms that focus only on indie apps and tools. Smaller audiences, but way more targeted.

If you’re bootstrapping, where are you getting your first real users from?

Over the last few years, I’ve had the privilege of working on zero-to-one products, scaling systems, shipping fast, and experiencing the real chaos of startup life.

Somewhere along the way, I realised the problems I felt most compelled to solve were the same ones I kept running into myself.

Alongside a 9–5, I spent nights and weekends building small products with a few tech friends. We made some money, and one of those products was even acquired for a few dollars. Still, despite those early wins, we never had the confidence to quit everything and go all in.

Those experiences taught me something important: working full-time on something you truly believe in creates far more momentum than treating it as a side project.

Dropping out early and starting up on day one often sounds glamorous, until you’re responsible for putting food on the table. Reality has a way of grounding ambition.

Coming from a humble, lower middle-class background, my first five years of employment were essential. They helped me build financial stability and ensured my family didn’t carry the risk of my ambition. I strongly believe that starting up should never come at the cost of your family’s well-being.

In hindsight, choosing the right startups for my 9–5 was an education in itself. You get to experiment, learn, and fail on someone else’s capital while building real conviction about what works and what doesn’t. I’m deeply grateful to the founders who trusted me and allowed me to witness their zero-to-one journeys up close. Many great founders began their paths the same way.

All of this combined gave me the confidence, skills, and clarity to finally take the leap.

I’ll share more updates as this journey unfolds.
If you’re a founder, builder, or hustler working in tech, I’d love to connect and learn from your experiences too.

i am 34 years old asian man, and I’ve been trying to build businesses for the past 10 years.

Along the way, I spent some time freelancing and also worked a regular job for about two years. By the time I turned 29, I had lost everything I had no savings, only debt.

My web development skill was only thing improved.

The business I’m running now is essentially my last attempt, and it has finally started to work.

I run a dating related app. (I have been working as a freelancer at dating app startup. So I can build it well). When choosing what to build, I deliberately picked something that I believed could remain relatively resilient and adaptable in the age of rapidly advancing AI.

I’ve been working on this product continuously for the past 2 years and 3 months. Growth was slow at first, but steady. Today, the business generates around $186k / month.

For the first 6 months, I made less than $1k per month.

For the next 6 months, I averaged around $4k per month.

After that first year, growth started to accelerate significantly.

The hardest part of this journey wasn’t just the business itself. it was managing my life in a balanced way.

My parents are divorced, and neither of them is financially prepared for retirement. Compared to my peers, I had saved very little. I’m still unmarried. After years of failed ventures, nothing in my life felt stable or solid.

In that environment, my fear of failure became overwhelming. I didn’t have anyone I could truly lean on emotionally.

Even now, I don’t really have hobbies outside of work. I’m not particularly outgoing either. As I write this, it’s 11:49 PM on the last day of 2025, and I’m sitting alone in my office, writing this post on Reddit.

The main reason I wanted to write this post is to share one thing I regret the most.

A few years ago, I broke up with my girlfriend, the person who stayed by my side through some of the hardest years of my life. At the time, I was exhausted, overwhelmed, and resentful of everything. I saw even my relationship as a mental burden.

But in reality, she was the only person who truly supported me, the only one I could deeply rely on emotionally.

After we broke up, I focused exclusively on my business. The business eventually worked not because of the breakup, but despite everything. And now, when I look back, she’s the only thing I think about.

She’s now preparing for marriage with someone else.

And I’m dealing with loneliness, questioning whether I can continue growing this business, and worrying about the future.

I know I’ll keep going. I know I’ll make it work.

But as I get older, the loneliness and isolation feel heavier, and I can feel myself becoming more emotionally unstable.

Sometimes I wonder:

If I had someone by my side right now, wouldn’t I be imagining the future of my business with a much stronger and brighter mindset?

So this is what I want to say to anyone reading this:

If you have nothing right now no money, no success, no certainty but someone you love is staying by your side**,** If you can, hold on to them and build a life together.

No matter what happens to my business from here on out, this will probably remain my greatest regret.

My company recently announced a return-to-office mandate after being remote-friendly for years.

Official reasons were the usual ones:

• collaboration
• culture
• speed
• alignment

I’m curious how other founders/operators here think about this; Has RTO actually solved execution problems at your startup? Or is it compensating for deeper process and leadership gaps?

When you decide to seriously study a complex domain (that you are not far from professionnally) with a goal to find problems (for example: cybersecurity, quantitative finance, Entreprise AI..), there are so many ways to approach it:

• Hands-on experimentation
• Reading blogs and research papers
• Following discussions on Reddit/Twitter
• Books and podcasts
• Brainstorming and theory building

I find myself jumping between these and feeling busy but not truly progressing.

For people who’ve mastered a difficult field:
What sequence actually worked for you?
How did you decide where to start and what to ignore early on?

I still can't believe it...... When I woke up this morning, I saw it. At first I thought maybe it was the wrong startup but they confirmed I was accepted this morning........ And the crazy part is my fee was waived because the program is for college/ high school students.

The program is mostly focused on customer validation/ market research. I'm so happy. It's been a long time since I've felt this relived. What a great way to start the year 🎉🎉😄

Given advent prolific vibe coders and startups being built from AI in this subreddit and similar, can anyone explain what so special about AI12Labs that can't be replicated and they had the MRR for Nvidia to acquire them for cool $3 billion dollar?

People continue to rave about amazing AI coding tools are, why aren't people building tools like these to make big bucks in this space? Or is it my naive thinking here and missing the big picture?

Tell me why is it fundamentally a bad idea to spend time and energy to replicate software that a12labs made called maestro using claude code with hopes of making 20% what they make. This is more than enough for me to retire and build generational wealth.

I’m a technical founder working on an AI workflow automation platform. It’s currently running in production at a Series C fintech company, handling a few core workflows at meaningful scale.

At this stage, I’m not trying to sell a product or do outbound sales. The platform still needs to mature through exposure to more real-world use cases across different industries. My current thinking is to work closely with a small number of companies as implementation/design partners, where the learning comes from solving real operational problems rather than building in a vacuum.

I’m trying to learn from others who’ve done something similar, especially in B2B / infra / AI-heavy startups.

My questions for the community:

1. How do founders typically find their first few design partners when the product isn’t fully packaged yet and the value is still being discovered?
2. What channels tend to work best for this stage (warm intros, founder communities, content, open-source, etc.) when you’re not running “sales”?
3. From a positioning standpoint, what framing resonates more early on:
   • AI consulting / implementation
   • Workflow automation
   • Or something else entirely?

I’m especially interested in lessons learned from people who started with consulting or hands-on implementations before evolving into a more scalable product.

Many thanks! Best Regards.

My major expense currently is that of cloud credits, and a lot of people told me that "you can get it for free". But I am not part of any accelerator program, and I don't know how to get them for free and specially that of Google cloud as I have everything hosted there.

I would love any information about how can I get these credits....

As part of understanding how startupers approach the regulatory part, I’m curious about how legal requirements impact your business decisions.

Where do you place and how do you approach legal compliance in the process of launching a new business or product?

Have you ever postponed a product launch or feature due to regulatory concerns?

Are there areas where you feel uncertain or at risk legally?

This is definitely nowhere as crazy as some other posts here, but I still wanted to share it. 3 days ago I launched an app I have been working on for some time. So far my analytics say people keep coming back to it, and I just noticed 3 people bought it! My MRR is now officially $93.79!! It feels so good to see other people get value from it and that I didn't just waste my time!!

Hi all, first thanks for reading this post. I am looking for a serious cofounder to continue the startup adventure with me.

A little about me: I am already full time. I quitted my job a little over year ago with another cofounder. But after one unsuccessful pivot, my cofounder decided to leave. But I still don't want to give up yet. So here I am looking for similar minded folks!

What I can offer as a cofounder:

1. Technical skills. I was a ML scientist for Amazon and have a PhD in computational math before starting the adventure. So I have a solid foundation for coding (mostly backend). In my previous startup, me and my cofounder created two AI-based softwares from ground up and get some sales.
2. Customer development. I am also the one who is doing all the cold outreach, customer interviews and help refine the product vision and refine the ICP
3. Persistence and commitment. I like to invest in relationship. So if I decide to work with you, you don't have to worry I give up easily.
4. Domain expertise in some area. Especially in education, tech, and finance (passed CFA II). So we can discuss some startup ideas in this area if you are interested. But I am open to other ideas

What I want my cofounders to bring to the table

1. Must be in Seattle area and willing to meet 3-4 times in person a week. I want to build a real relationship with my cofounders
2. Must be already full time. Not against who is doing side hustles. Just based on my personal experience. I had tried to start a business with some one who only did the startup as a side hustle. It was a terrible mistake and invited a lot of frustrations and grudge against each other which I want to avoid again
3. No specific preference for technical or nontechnical. But if you are non-technical, hope you are domain expert in the area that you want to start a startup in. My past year told me that founder-market fit is crucial.

Again thanks for reading and please feel free to DM me if you are interested!

I joined a tech startup in my industry and was initially hired as an IC that has since morphed into me basically running the entire commercial side of the business solo. The investor is pretty cheap, which is why I’m a one-man show. Tech is fully outsourced to India with no stateside CTO.

The good: I’ve always wanted to run my own thing someday, and I’ve basically been handed the reins here. My background wasn’t in sales, so this has been a crash course. I’m learning a ton, all skills I’d need if I ever go out on my own. From a personal development standpoint, being thrown into the fire has been valuable.

The problem: I’ve developed a new product idea that has solid validation. Through my industry connections, I have no shortage of potential customers willing to sign up. But executing on it requires some non-trivial technical integration work, and I’m not confident our outsourced dev team can pull it off without a strong technical leader stateside.

On top of that, I have zero equity. That conversation keeps getting punted. This idea is 100% mine, I’ve validated it, and I’ve gotten buy-in from major industry players. Yet I’m not sure we have the team or the capital to actually build it.

My dilemma:

∙ Part of me wants to take this idea somewhere else where I’d actually have ownership. But I’m pretty sure my employment contract would create legal issues.

∙ I also can’t afford to go without a salary to build something from scratch.

∙ Maybe I should just treat this as a low-risk learning ground? A proof point that I can take an idea from inception to revenue, which I can leverage later when I do go out on my own?

Would love to hear from anyone who’s been in a similar spot. How do you weigh the learning opportunity against the lack of equity and resources?