
Ask HN: Partial Bootstrap for a SaaS Startup - mozey
I&#x27;m an average full stack developer working freelance. I&#x27;ve got some experience managing myself, and mentoring other developers, running a business not so much. Currently I have the luxury to spend about a third of my time working on side projects.<p>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.<p>One model for funding is a single client that pays upfront (at discounted rate), with the understanding that it&#x27;s my product, and I&#x27;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&#x27;ll need a MVP to generate some interest.<p>Another approach is to pay for the project with my time, maybe also spend some savings paying contractors. I&#x27;ll be invoicing myself for developer time.<p>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&#x27;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?<p>Anyone tried this before, any tips or recommendations on how to structure such an agreement?<p>Tbh, I imagine the subscriptions only making a modest amount of profit if the project is successful. I&#x27;m fairly confident the bootstrap cost can be kept to a minimum. If costs start spiraling, or subscriptions just don&#x27;t sell I want to walk away and continue doing contract work.
======
davismwfl
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.

~~~
utopian3
> 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?

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

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

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

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

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

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

~~~
dillonmckay
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’.

------
encoderer
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?

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

------
jeffshek
[https://www.indiehackers.com/](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.

~~~
Pandabob
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/](https://www.startupsfortherestofus.com/)

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

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

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

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

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

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

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

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

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

------
hazard
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...](https://consumer.findlaw.com/securities-law/what-is-the-howey-
test.html)) 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

------
gjvc
Might this help the exploratory development?

[https://github.com/saasforge/open-source-saas-
boilerpate](https://github.com/saasforge/open-source-saas-boilerpate)

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

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

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

~~~
kreck
"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

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

------
sharemywin
you might check out some of this:

[http://startupclass.samaltman.com/](http://startupclass.samaltman.com/)

on talking to users.

------
sharemywin
I would build a landing page first.

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.

