If you're building something with the goal of selling it, sell before you build. This applies in at least 99% of cases.

Just go to potential customers and tell them "hey, in [a few months/years], I'm going to launch a thing that can do this and that for you. Would you like one at prelaunch price?"

If customers don't like your initial pitch and don't buy, why would you give up? Iterate on what you're selling. You don't need to build to iterate.

Then you can build something people want.

I like to phrase that as "as a software consultant, I'm in the business of not writing code. The first rule of this business is to never write code until somebody definitely wants to use it".

Of course, if you're building it just for fun, iterate on the code all yu want before you sell it.

Your comment is the essence of why I totally hate software consultants.

"Hi customer, after months of meetings and calls and briefings and checklists and ... here is my final 76 page presentation about an ideal not buildable extremely expensive software that if finished will look like Homer's car"

Never had experiences different from the above, be it from big or small players.

I have never delivered slides as my deliverable. I take projects where the deliverable is either running code written by me (when the code is really tricky to get right) or a product/feature launched by the team I'm supporting.

There are consultancies in the CYOA business, and consultancies (or, usually, single consultants) in the delivery business. Both have high customer demand, for different reasons. Admittedly, the first kind usually make a lot more money, but I live nicely.

You sound much more a freelance developer or a single person development agency than a software consultant, I guess we simply describe those roles differently and don't assume the same thing when talking about "software consultancy".

The thing you are describing sounds like the first phase of a project where you are gathering the requirements, in a one-to-one business relationship with a single customer. "Sell before you build" as far as I understand is usually used in a one-to-many scenario, where you start selling (or better, marketing) a product before building it.

As of today, I have an employee, so definitely not a one person agency anymore.

And it's very rare that I'm engaged to write a complete system, because I'm quite expensive.

However, from the way I approached the answer you can easily tell I'm a software person and not an MBA/salesman by birth.

Usually I work with startup CTOs (which I was myself until half a year ago) to solve very complex business or technology problems or support the design and development of a complex project. For example, you might engage me to perform design reviews with your team, or to dive into the code of a system written in a language nobody in the company knows and add a complex feature that sends ripples across the codebase, or to design a critical system and then write the most complex module myself and stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs. I really am a consultant, just a software consultant, not a "management consultant", like McKinsey or Deloitte.

"Sell before you build" means before you waste resources building something, have expectant customers waiting for them to exist, with money already committed to buying it once it exists. There are many ways to structure this commercially. Of course you should sell one-to-many, not just one-to-one.

Many times the first thing I tell a potential customer on a sales call is "wait, you want to build this before you have paying customers? Why take all this risk? Go out and sell it (or market it, if it's a B2C product) and then build it without the product-market-fit risk!" I then go into the many strategies that exist for selling things before they are built, as they apply to their specific industry and business. This can save my customers millions of dollars or years of their lives if they're at the first stages of a startup. This kind of thing is a major reason I can charge consulting rates and not freelancing rates, and is essential business advice that every serious entrepreneur either learned the easy way or the hard way.

We are converging :)

I guess it is just a matter of terms, I would have never called what you just described as a "software consultancy" since you mentioned building, developing, code reviewing and such terms a lot of times.

By talking to you I understand that the meaning I give to the word "consultancy" is not as universal as I have thought. For me consultants never dive into anything "practical", they limit themselves to aspects of the software that stay all around the actual development.

From my point of view you I would call you an experienced freelance developer, or a development agency (congrats on growing BTW, going from 0 to 1 employee is a big step). Mind that developing is not simply coding, so IMHO you are still a developer even if you "stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs".

You happen to advice your customers about stuff not strictly related to the actual development process, and that would be a consultancy, but it doesn't sound from all your comments that this is your main focus so from my strictly personal point of view I wouldn't call you a consultant.

Developer: code, output, stuff that works and implements some business logic.

Consultant: advices, indications, expectations... and then it is up to someone else to make it work. (and they don't care if ever, how, when, why, who)

Anyway don't take it personally, and by the way I didn't mean to be disrespectful towards you. Maybe my first comment was a little harsh, so I'm sorry if you felt it as an attack on your person or your professionalism :D

I think your use of "consultant" is less correct but closer to the common perception. Consultants that deliver measurable KPIs and not just heaps or documents are less common.

I'm an uncommon type of consultant, but definitely not a development agency or software freelancer. I help my clients build things, but I don't usually build things for my clients, as that would be too expensive for them.

> I'm going to launch a thing that can do this and that for you.

This is just selling an idea, not a product. You can sell anything this way, just promise something and trick them into buying, it doesn't mean that you can actually deliver on that promise.

> Then you can build something people want The problem is that you don't know what people want. People don't know what they want. It's hard to know how to solve a problem or if a product will work unless you try it, there are so many unforeseen issues that can arise once the product is"done".

You don't have to trick them into buying. You can just convince them to buy, eyes open.

> doesn't mean that you can actually deliver on that promise

It's very rare that the big risk in a problem is technical feasibility. And you should definitely be, or partner with, someone who can tell the difference between a spec that can be built to a spec that has real technical risk, and only sell things that you can deliver.

> The problem is that you don't know what people want. People don't know what they want

Indeed, and the only real way to tell is to build it. But you can de-risk by selling a few first and then building, instead of just investing years of your life completely blindly. And there's no reason not to. It's very rare that a product idea can be sold once it's built but not before, and there are other, less risky, products you could build instead of that one.

Kickstarter is filled with "fake" projects that are only selling an idea which is often impossible to implement. It's not only about being able to create that product but also matching the promised delivery times, R&D costs, manufacturing costs, etc.

Same goes for:

- Putting up a landing page with an email collection form at the bottom without a strong value-add for the potential user

- General idea of MVPs (not saying MVPs don't work, I'm saying the way we're told MVPs have to be bereft of features and polish is bullshit), though this has mostly been replaced with Minimal Loveable Product.

- The idea that you have to be first/second to an idea to make money from it (I was 200th to my idea, it's profitable)

- The idea that you have to quit your job and "hustle hard" to make a product others will want (I did it in 2 hour chunks before work)

"Sell before you build" is the tech elite's "let them eat cake". It's literally impossible to do unless you have the right connections and raised funding from the right people.

Unless your startup received massive media exposure, nobody will part their money for a product which does not yet exist... You need exposure to massive numbers of people to get any measurable success... And without the right personal connections, it costs a prohibitive amount of money to get that kind of exposure. If you're a developer, it would be cheaper for you to build the thing and then try to grow linearly over the years than to pay the cash up front to achieve that kind of reach... What if your product doesn't measure up to expectations? This is a real risk if you got your customers through advertising (selling a dream) instead of winning them over slowly through a superior offering. The problem with selling a dream is that it's essentially impossible to make reality match the idealised image which you projected into the customer's mind... Even in the cases where it does seem to work out and customers make repeat purchases, the product may just be a superficial representation of what the customer actually needed and it could take them a few years to figure out that the product was itself just an extension of the dream, a shell of a solution... There are better alternatives out there.

The building spectrum covers from consulting on one end to crafting on the other end.

The first step is to know yourself. Which style are you? Which style you want to be?

If you are on the consulting end, talk to people, understand the problem, build a solution, and iterate on it. This is how software has been preached to be built for decades. Waterfall/agile/whatnot are all the same, assuming idea come from somewhere and keep iterating your solution.

If you are on the crafting end, you have an ideology to preach. Akin to art in any form, you are both the source of idea and executor. You broadcast your ideology and look for followers. Rich Hickey of clojure, Mike Bostock of D3.js and Bret Victor are on this camp in my opinion.

Note that you can hop between crafting and consulting/iterating. But iterating is like newton method, no amount of iterating will get you to answer if the initial guess is too off. So one has to have strong conviction to craft an initial solution with good enough quality before launching into iteration cycles. I've seen many "metric-minded" product people obsessed about iteration without having any conviction on what to build. Without the initial conviction, no amount of iteration can give you clojure, d3.js and co.

I don't remember the last time I signed up to a mailing list just to be notified when some random app goes live. Let alone pre-ordering.

I would do that if I already trust the organization, which implies it has already launched useful products in the past. For an unknown startup, the idea would have to be truly Earth-shaking for me to sign up.

In most cases, I'll just wait until I hear that the app is out, and then try it and consider purchasing.

To me, "sell before you build" is a no-go for upstarts with zero audience, whereas "market before you build", or maybe "market as you are building", creates the awareness you'll need to warm people up when you are ready to sell.

This just means that you are not the right customer for a lot of early startups. But it would be a mistake to extrapolate from this anecdotal point, assuming that everybody is like you. There are a lot of people who are very happy to be early adopters, find it fun and valuable to them and to the society.

It could be a bit dangerous to rely only on those when building your startup, but having a good combination of these early adopters and pre-sale conversations with late adopters is super important.

Zero audience is not a problem btw since a) there’re are usually relevant communities, b) there’s trivially automating cold outreach that is a single best way to test your PMF hypothesis.

Edit: typos

While it's true that extrapolating from "me to infinity" is a logical fallacy, that's not the same thing as saying (in the general case) "even if you think it's a bad idea, there will be a lot of people who want it, therefore it's still a good idea", regardless of the reasoning behind why the one person you're talking to thinks it's a bad idea.

In this case, I think there's a strong argument to be made that while yes, there are people who will be willing to buy into an unknown startup's unreleased product, by and large, those people are fools (in the sense of "a fool and his money are soon parted", at the very least). There's certainly a segment of our population (which is, completely unsurprisingly and reasonably, overrepresented on HN) that's very excited about startup culture, and wants to believe that any given startup is going to Change The World™...but far, far too many of them fall into one of three categories:

1) Come up with a "new" way of moving money around so that rich people get richer (eg, the entire cryptocurrency space)

2) Make something that looks just flashy enough for them to get bought out by a bigger company

3) Fail outright

I disagree with this interpretation.

It is a question of versioning and packaging. Basically, v0 of a product is for testing the initial hypotheses that people are interested in buying at all. And it also serves as a tool for finding the initial "fans" that are excited by your product vision and will help you flesh out the product.

"Sell before you build" is just way to communicate this.

btw: The post is very short. Here it is:

> This is such bad advice. It assumes that everyone will nail their product on the first go. Almost no-one does.

> If I went to customers and pitched Songbox to them with what was the initial version of it I had in my head - I would have gotten nothing. And if I'd given up on it at THAT point then I would have missed out on (a couple years later) having a business that's well into X thousand MRR and even more importantly, working with some amazing people and having truly exciting and unique experiences.

> There is no doubt that "sell before you build" will work for some people; but everything and anything will work for SOME people.

> For the general populace of makers it is crushingly bad advice.

Maybe this is the misunderstanding. Reaching out to potential customers is not about "Look here is my idea of a hammer. Would you buy one?", but understanding which problems are solved, which benefits are achieved, which tasks are done, if there was a hammer like that. The bet is that this can be learned faster and less expensive via communication than developing.

IMHO I don't think you can have real product fans without a product as much as you cannot have music fans without music.

They might be fans of you vision, of your marketing or whatever else but that can be as bad as it can be good when your product finally lands.

I suppose it's good advice depending on your target audience.

Generally, a lot of indie hacker types of entrepreneurs just like building cool things!

A bit more proactive on the communicative and sales side is not a bad thing, but I believe it's best to play to your individual strengths.

Same here with "just for the cost of a cup of coffee" as a coffee hater and I also think if I pay cost of one coffee here, there and elsewhere them in sum it's much more than cost of a cup.

Same thing goes for 9 out of 10 pieces of fortune cookie entrepreneur advice

Didn't take long for this to be curated off the front page of HN. Is HN losing traffic to IH?

Let me tell you that it's hard to work with softwares first...

Let me tell you that it's also hard to find skilled ppl in the context you wish to exploit.

Let me tell you I saw many clowns telling they are good with computing...

But unaware what a heap memory. Says a lot. :)