I would like to try use this time to bootstrap a startup. The focus will be enterprise software for a specific industry, unrelated to my other work. However, I do have some insight, and connections to this industry. I want to manage the project as a single developer and eventually sell subscriptions to SaaS.
One model for funding is a single client that pays upfront (at discounted rate), with the understanding that it's my product, and I'll eventually on-sell it. This is not practical in the industry I want to focus on. My product should be impartial, not associated with a single player. An idea only will be too hard a sell, I'll need a MVP to generate some interest.
Another approach is to pay for the project with my time, maybe also spend some savings paying contractors. I'll be invoicing myself for developer time.
It occurred to me that I can give people the opportunity to buy in by paying a part of the cost. Maybe even pay for specific features. As incentive, rather than shares in a business, I would offer future profit sharing. Investors can buy in at any time and pay as much or as little as they want. The profit share is determined by the fraction of dev time that you've contributed, or paid for in cash. Does this make sense, am I using the right terminology? Am I just describing a specific type of share ownership in different words?
Anyone tried this before, any tips or recommendations on how to structure such an agreement?
Tbh, I imagine the subscriptions only making a modest amount of profit if the project is successful. I'm fairly confident the bootstrap cost can be kept to a minimum. If costs start spiraling, or subscriptions just don't sell I want to walk away and continue doing contract work.
I lucked into a situation with one product where basically a client needed a tool to do a job but it was something we had solved like 6 times in the past couple of years, so we knew there was a market for it. So we did team up with him on it essentially. He had no interest in the product part, just needed his problem solved, but he liked the idea of a discount on his dev fees. So what we did is cut our dev fees to him (still covering our costs), he got a worldwide non-exclusive license to use the product but not to resell, and we kept the rights to resell. So in the end, he got a product & free support for a period of time (at a steep discount) and we got a money maker, not great money but real money.
The second time I just sucked it up and used off-time and down-time from consultants and myself to build the product. While it took us much longer, and nearing launch we had to dedicate more time to it which meant me funding a couple of people full time (versus just down time hours), I would say I preferred this route. It meant we didn't have to compromise on features, or develop a feature we felt/knew had no basis to be in the product. What I liked was we could focus on making a product first, which is hard to do when you are essentially solving someone else's problem. I'd do this route again over the other just for the simplicity, yes more risk, yes longer time to market, but much less of a compromise which you then turn around and spend months fixing later.
1) pick the one problem you are solving and do whatever research / market sizing you need to do to feel more assured that your proposed solution is meaningful enough to pay for and enough people have the problem to be worth the while
2) spend a lot of time with your pilot costumer. Their time is worth more than their money. Say you are deeply committed to building it and when you do they can have it free for a year. So many great SaaS businesses were built this way and it’s a fair trade
3) build quickly and drop any feature that doesn’t facilitate point 1 above
This is all high level. Happy to chat more over email or Call about specific tactics and strategy. Good luck.
Edit: Just finished late breakfast, have one more item to add:
4) don’t obsess about hitting grand slams (ideas that can make $100mm in ARR for example). You can live a very good life with a small team of people you like and respect with a SaaS business that does $3-5mm a year. VCs hate these but trust me, you’ll love it.
Devs need to flip their focus. Instead, spend a lot of time with customers, build marketing landing pages, which include mockups of the software, and see if you can attract paying customers. Gather feedback early and often.
Once you're successful with that, you'll have a clearer path of what to build. Then go build it.
The magical part of this approach is that you'll have most of your sales and marketing pitch down by this point, so launching your project into a business will be so much easier and more likely to succeed.
every single person says that, but the reality is a lot more likely to be the thing you want to build doesnt have enough value to the customer to part with their cash today.
Also agree with everything below. don't worry about this stuff right now. The sole focus should be what problem do people have that I can solve. Once you figure that out, and build an MVP, then you could worry about fancy business design.
"Getting the flywheel moving" is an incredibly hard part. You most likely will never move past this stage, which means all energy spent not trying to solve that singular issue will result in waste.
As far as paying for features, Id also strongly suggest against this. Initially, and for years to come, if your project is successful there will probably only be 1 major reason a customer hands you money to solve their problem.
This might be bc you save them 10 hours a week of manual labor, or ensure no mistakes are made while processing time sheets or guarantee uptime for production (whatever it is). Even though that might sound like very few people want it, if you can find a few you are on to something.
Anytime spent building a feature because a client paid for it will not be time well spent (all things considered).
I work on an enterprise rapidly scaling b2b SaaS app in finance space. We took lump sums early on from customers and now have 5-6 different "features" in our apps that have to be maintained, supported, all unique to 1 financial institution.
It might not sound like a lot, but when you're trying to get developers up to speed, help them understand the code base, and there are things like that, it really costs, and those costs scale exponentially.
Each feature we have to ensure works with this, doesn't break anything. etc. when we only had 2 developers this was something everyone knew. Now that we have multiple teams, its really, really expensive.
Tread lightly. Solve the first problem in front of you fairst (find a problem people will give you money TODAY to solve). If you succeed at that, you will have $$$ to solve your other problems.
Contractors would be an awful idea. Expensive, inconsistent. You are standing by your product you should know/trust every line of code in the beginning.
Why are you invoicing yourself for your time?
What your suggesting does sound a bit like dividends. Give early employees shares directly and pay them pro-rata on the percentage of shares they own via dividends from the profit. Perfectly valid, possible tax implications and maybe not a long term solution if the company grows to more than a handful of people. Giving people shares directly also removes the long term incentive to hang around.
In truth getting to profit with enterprise software will likely take years. I’ve been running an enterprise software business for almost 3 years and we’re absolutely no where near profitability.
The Mom Test (Book) is a way to verify the thing you're building people will actually want. Providing market-fit can be hard.
Startup School by YC is another good resource to keep you accountable and make progress with your ideas.
I'm doing the same thing, building a SaaS that clients are using that I will market to a wider audience in the future. I'm using my 20% time and have built out just enough that I can charge clients for the service my SaaS provides. I invoice them manually currently.
I wouldn't mention about it being a SaaS or them funding the development, and definitely not anything about a discounted rate. If they are asking for a feature/service build it and charge them an onboarding or initial fee + monthly fee to cover some of your costs. Deliver it as a service they sign up for you can invoice them manually initially or integrate stripe in to it or do that in the future.
You'll have some signups and can catch bugs, improve the service, take feature requests, get signups. Using the revenue to cover some of your costs.
If a client asks for a new feature you can introduce an add-on to his subscription and/or an additional one time fee.
Note in your contract this is offered as a service, you retain all rights to use/resue/resell the code and offer subscriptions to the service. The client has the right to subscribe or unsubscribe from the service. You have the right to wind down the service after XX months. Prices and features may change in the future.
If the service provides value don't sell yourself short, SaaS is an amazing business model. Granted it's a slow ramp, but amazing the revenue even a small team can generate.
The Build Your SaaS podcast is good too.
>Tbh, I imagine the subscriptions only making a modest amount of profit if the project is successful. I'm fairly confident the bootstrap cost can be kept to a minimum. If costs start spiraling, or subscriptions just don't sell I want to walk away and continue doing contract work.
You are setting yourself up to quit. Unless you fall into something that people are willing to immediately throw money at then starting a real business is hard - especially as a solo founder.
You don't sound that excited about the actual product and it doesn't sound like you think its a billion-dollar idea, so why are you doing this?
Your 1/3 extra time is better spent finding an idea you are so passionate about you can't just walk away or working harder in your existing job to further your career and open up more opportunities in the future.
Create your MVP mockup and try to sell that.
If you do not raise enough to fund your bootstrapping, refund the money and move on.
Generally I think it's worthwhile to think of customers and investors as separate entities and use established paradigms to deal with them. Ultimately you could have a combined customer-investor, but the deal needs to make sense from both perspectives. Learn about seed stage investment and how deals are structured in order to balance control with the interests of both sides.
If you're not careful it would be very easy to set up a deal with radically misaligned expectations on both sides, and without the right structure, a customer-investor could end up taking you for a real ride.
There is nothing like having a paying customer to tell you what they need. Then the next two customers comes along they may need something entirely different. You won’t have enough data points until you get a few customers to know what to generalize. It’s the standard “Rule of 3” in software architecture.
In short, if you go this route, you should look at not just the business trade-offs but also the legal implications. You can probably get a brief opinion from an attorney for somewhere between $0-$500
Enterprise is also one of the hardest markets, not only technically, but also getting clients (3-12 months from first contact to money in the bank is normal). Enterprise is also a game where they don’t buy the best software, a lot of factors play a role in getting enterprise clients. It’s doable but definitely playing a new game on hard/insane level.
Focus on the problem that you solve for the business, without a very strong case for that and be able to gain a champion within the company you are selling to, it’s near impossible. As you can see its more about sales, and connections, and less about product.
I’ve been in your situation before serving enterprise SaaS as a two-person company for 5 years. It was very hard and I would not do it again. Then again, once we got clients they were easily paying $30k/yr with long term contracts in place. High risk, high reward.
If you are starting out you have different levels of risk you can take. Since your real prime-time years are at stake, are you going to play this game on hard right at the beginning? I’d suggest to start on easy, get more experience, and as you grow, level up. Once you have a couple $$$ in the bank, do bigger projects with higher risk/higher reward ratio.
That’s what I wished someone told me 10 years ago.
If I were you in this situation now, I’d first warm up those connections, as they will play a crucial role in your company. Is it something they want or need? Is the pain they are experiencing so hard they are willing to prefund the project? If you think so, try convincing them to get either dev money beforehand (hard) or have them sign a binding (hard) or non-binding (doable) agreement to pay xx amount when the software is ready. Include what features/problems you will solve in the agreement.
Your ideas about profit sharing are too complicated in my opinion.
If you are not able to convince them to prefund or either sign an agreement, for me personally this would be already too high risk. Unless those connections are decision makers and you play golf every month with them ;)
That’s what I would do in your situation and my 2 cents.
Wish you all the best of luck, not want to discourage you, but sharing my own experiences in a somewhat similar situation. If you need advice, help, or just wanna bounce some ideas, always willing to help out fellow entrepreneurs.
So, that you focus on the sales pitch. What is the key benefit. what problem does it solve? what are the three things that will guide people to want to use it.
maybe blog about the problem. and get it out to your potential audience.