Ask HN: Bootstrapping an Enterprise Startup

Sell on-premise software then You get most of the money upfront.

Thanks. I think we’re still a few months away from actually being able to sell something. The other challenge we have is our value depends on the customers’ data.

alchaest 5y ago ↗

indiehackers.com

codingdave 5y ago ↗

One option is to partner with your first customer - they fund the development, with discounted hourly rates, in exchange for you keeping the IP and being allowed to resell it as a product once the initial launch with them is done.

That is easier said than done, though - you need to be developing something difficult enough that their internal staff cannot do it, with enough value that it is worth a line item in their budget, and that does not have existing COTS solutions.

tixocloud 5y ago ↗

Interesting. Any ideas/thoughts on finding companies like that who would be interested in partnering? I’ve heard of this but most companies I’ve approached tend to defer to their normal enterprise sales cycle.

codingdave 5y ago ↗

I suspect you won't find such a partner by cold-calling. You have to have someone who trusts your work and has the authority or influence to bring you in. I'd think back to anywhere you have worked in the past, or past co-workers who have moved on to new companies, and get back in touch.

shoo 5y ago ↗

I've seen this model used to develop domain specific decision support software used to help customer optimise costs. Required a few person years of R&D to hit proof of concept & get a contract signed, then contract was large enough to fund a small business & grow headcount for several years.

One potential trap is over-fitting the software/product to what the first big customer wants, or getting carried away spending too much time doing random bits of customer specific consultingware, and not being able to factor out a product that can be generalised and sold to other customers with somewhat different requirements.

Jugurtha 5y ago ↗

We did consulting. We did custom, turn-key, machine learning products exclusively for large enterprise for many years. That wasn't just building the models, but everything from digging into ISO standards for rail transportation, to data acquisition, infra, building models, writing applications, and sometimes having custom hardware made for very specific signals of interest. Tiny team. Repeat business as our clients rely on us more and more with a history of delivering.

We're builing our machine learning platform[0] to remove as many problems we had faced as possible and execute projects in a faster, more reliable, and more consistent way.

I had a big grin a few weeks ago when a client was describing what was to be done, and I DM'd our CEO saying that this was about three months of work we wouldn't be doing, after it had saved us about two weeks of work up until that point.

To recap: we did consulting, learned a lot while being profitable, then leveraged what we learned and all the problems we had and the mistakes we made to build our machine learning platform to get data projects right.

I wrote a bit about this in a twitter thread[1]. Feel free if you have questions, as I think we're in similar situations for similar clients.

Thread reproduced here for convenience. Context: Projects are in the mid six-figure range, a couple of individuals can pull the project off. Clients are large corporations. Domain is machine learning (turn-key, taking clients from puzzled look to wide smile).

===

0. Form:

0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.

1. Contracts:

1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.

1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.

1.2. Retain intellectual property to amortize engineering and sell what you make to others.

1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.

1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.

2. Presentation:

2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.

2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.

2.1. General presentation with broad strokes of your capabilities, including previous work with other clients

2.2. Conversation with the prospect on their worries in a given space

2.3. Conversation with the prospect on their worries in a given space

2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.

2.5. The client finds one problem urgent/highest priority/highest value

2.6. You get together and talk about "desirability, fasiblity, viability".

2.7. Once you agree on what to do, prove the concept.

2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.

3. Execution:

3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.

3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're...