So I built 2 different SaaS products out of my own consulting agency (that actually made it to market). And I did them both differently.

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.

> 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.

Isn’t solving someone else’s problem the point of a product?

Yes, I agree that is the point of building a product. The one catch there, is when you have a client paying for development there are compromises and time to market considerations to which can affect having a product available to the wider audience.

In our case, we were working both with the client we were building the product for initially and also we had prospected a number of other clients and were trying to get an MVP out that solved the problem and then iterate. However, that didn't work for the primary client and a number of things he wanted in his MVP were not good general product market fit, which made it harder for us to manage the timing & expectations. So while it was overall less expensive initially out of my pocket, the timeline was dictated/dominated by the client and special features they needed which took away from making a generic product that we could've had in the hands of others faster. Which in the end meant we had more product/development churn then if we had gotten the more generic 80% MVP out for a wider audience.

That's what I meant by we could've focused on general product first.

We bootstrapped our SaaS company. My advice:

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.

The largest problem developers have with bootstrapping a project is that they focus way too much on building vs solving a customer pain point. This leads to bloated MVPs and little feedback from customers.

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.

I can also read it like this, though:

> The largest problem d̶e̶v̶e̶l̶o̶p̶e̶r̶s̶ people have with b̶o̶o̶t̶s̶t̶r̶a̶p̶p̶i̶n̶g̶ ̶a̶ ̶p̶r̶o̶j̶e̶c̶t̶ doing their own thing is that they focus way too much on b̶u̶i̶l̶d̶i̶n̶g̶ what they like to do.

Isn't that the whole point of doing your own thing, though? If you really want to make money (desperately) the strategy would certainly change, but a lot of developers are really just pursuing a hobby or side project with a (probably unrealistic) dream of striking gold.

I suppose it could. I guess one would need to look down deep to understand what would make them most happy in the end. Taking the risk of running a business should be part of that consideration.

Personally, doing my own thing has been about personal freedom and optionality. I don't think you need to make it big to fulfill that dream.

Many people believe that you need to build a billion dollar company or you've failed. There is nothing wrong with making a $100k/year business and enjoying the fruits of your labor.

Happiness should be the goal.

This. Also read the book “Challenger Sale”. Solutions, not products, earn you money.

Ive done this a few times. 1 more successful than others. I would strongly push back on presales not being a possibility in your industry.

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.

So, to expand a bit on the concept of paid features, my current strategy, I give two options:

1) The paid feature, if it is based on a fixed fee, includes a warranty period, where we will prioritize fixing breaking changes as other parts of the codebase change.

Once the warranty period is expired, it required additional payments to fix the feature.

2) No warranty, but the feature cost increases their monthly or yearly SaaS fees, and requires advanced notice if disabling the feature.

As long as the user is paying for the feature, development resources will be devoted to maintaining it.

This also helps steer customers toward option 2.

Honestly, I use both these strategies more-so to prevent wasted time with feature requests the customer has no interest in paying for.

It forces them to find value in what they are asking for, not just because it is a ‘great idea’.

You are over-thinking this. Just build software and sell it.

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?

Lot of very valid advice on achieving product market fit and ticking through the early stages of the business in the comments here. Your questions seems to be more focussed on ”assume I have pmf, would a profit sharing structure be a valid way to incentivise developers / early employees”.

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.

https://www.indiehackers.com/ is a great resource around this.

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.

Indie hackers is definitely great for this kind of content. I'd also recommend "Startups for the rest of us" [1], "The art of product" [2], Patrick Mckenzies blog [3] and Stripe Atlas guides [4]. The first three resources all pretty much describe how to bootstrap SaaS-companies, while the Atlas guides are more general guides for businesses. Finally there's an excellent episode on Reid Hoffman's podcast "Master's of Scale" interviewing the founder of Mailchimp [5].

[1]: https://www.startupsfortherestofus.com/

[2]: https://artofproductpodcast.com/

[3]: https://www.kalzumeus.com/

[4]: https://stripe.com/atlas/guides

[5]: https://mastersofscale.com/ben-chestnut-the-case-for-bootstr...

If you haven't already check out the podcast startupsfortherestofus.com Rob has lots of great advice on stair stepping. Also check out tinySeed for when you get traction.

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.

What is it that you are trying to build? Tough to recommend practical advice or monetization/funding strategies without knowing more.

>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.

You are over-complicating this.

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.

The profit sharing part sounds odd as described. Cost of dev time is constantly increasing at a variable rate, so there would be automatic dilution baked in. Similarly by accepting any amount of money, you could be giving away a majority stake (and making a major commitment) before you even get started.

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.

* 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.*

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.

Be careful about the legal side. Whether it's shares or "future profit sharing", you may be offering unregistered securities. The Howey Test (https://consumer.findlaw.com/securities-law/what-is-the-howe...) is what you would typically look at to decided if what you're offering is a security or not.

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

Might this help the exploratory development?

https://github.com/saasforge/open-source-saas-boilerpate

Thanks for the comment.

I'm not looking for technical advice on how to implement SaaS. I've done this a couple of times before with various technology stacks.

I'm more interested in how to fund development, and fairly reward backers if the project is successful. What type of agreement can I use to implement this?

Ideally, potential clients might suggest and fund features, then be rewarded with a discounted or free subscription.

Find a company that needs what you offer. Offer to build it for them for X dollars, you retain all IP. This is fairly common in development. James Altucher also talks about this somewhat regularly.

The real cost is your time. Projects always take longer than you expect, especially if you haven’t done it before (the business part). Product is the easiest and has limited risks if you have decent dev skills.

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.

"The real cost is your time." -> this.

we've been doing this for the past 4 years, but as i really started to enjoy sales, things are going quite well, so i'm just adding my 2 cents:

From my experience the sales process is the only thing that matters. No client cares about the software (at least initially). Although this is/was tough to hear as a softwareenigneer (i didn't believe it either), if you're in B2B and trying to solve a serious enterprise problem, most of the readily available info on "how to start up" on the web is not applicable. All the talk about "build a fancy landing page", "build an MVP", "test your market first" did not help us. This is because we found that our target audience is not really active on the internet and the amount of potential DECISION MAKERS/BUYERS (not users!) is in the thousands to tenthousands not in the millions. Therefore we needed direct sales, whether we liked it or not. And initially that's a founders job. See this as a hint for my claim: B2B companies that are turning over many millions of dollars per year often have "a website" (which looks like it's 1999) but that's basically it.

Why? The clients are in B2B as well, so the level of doing business is mostly person to person, establishing a relationship. You don't need a fancy website for that. The reason is actually pretty simple: If you are solving a relevant business problem in B2B the duration of the anticipated business relationship is 5-10++ years. Depending on WHAT problem you solve the dependency on the clients new supplier (=you) is very high. Therefore a client cares much more about WHO that supplier is. Building that trust takes time and interactions, and that is why B2B is so fundamentally different from B2C where you have everything from one-off interactions to product-lifecycles of 1-3 years (max).

It was therefore always clear to us that building a viable B2B business takes 10 years.

So what did we do? Initially none of our clients cared about the software but about the business problem we solve and the people/the company who they are doing business with. We funded our product development by doing a mixture of pre-financed dev work & "contract software dev/consulting" with the IP remaining with us. This allowed us to build a product and use the references to get to work with the next clients. Over time this lead us to our (now SaaS) product.

B2B is tough, but as soon as you're in, you're in.

edit: typo

I'd love to hear how you went about getting invited into the club. In particular, how did you develop your first contacts?

you might check out some of this:

http://startupclass.samaltman.com/

on talking to users.