Since this is an audience of passionate technologists, here's the top piece of advice I have:
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.
This is excellent advice. There is a local company near me that has been working on their SaaS for almost 2 years now and still yet to launch. They started it on Angular 1 and are now re-factoring it on Angular 2 (or maybe 4 now). During this time they released a small open source Angular library but not even an alpha release of their own product. Keep in mind their product is not gear towards devs. They also hit every Angular conference they can and are always doing dev meetups. That is fine for after you launch and are making $$ but seems like a lot of wasted time and money when you have yet to release a product after 2 years.
During this same period, I launched 2 SaaS products on boring PHP 7 and Python for the backend and HTML, jQuery/intercooler.js for the front-end. Both profitable and growing.
I think sometimes devs don't realize the hardest parts of starting and growing a business have nothing to do with code or the tech stack you choose. Marketing, getting and retaining customers and everything else in between is way harder than writing code.
Why? Because it doesn't reduce cognitive load. One seems to require at least as much brain space to code things in Angular, as you do just writing pure Javascript. That's a no-no, that means it's not a labor-saver long-term.
From what I understand, the CEO had a previous company that repackaged, setup & sold custom social network software to companies. He made decent money while it was hot and is using that to fund this endeavor. I guess you can't really blame him if he is self funding. I don't feel right about calling them out by name. I hope it works out for them in the long run.
Both SaaS apps. Different markets but one of mine is similar in complexity to theirs. They could have launched a year ago if they were not wasting time re-writing the app in Angular 2 & 4 and spending time open sourcing Angular libraries.
I personally do not want to spend time re-writing my app every 6 months before it is even launched. I would much rather spend the time acquiring customers. I tend to choose a stack at least to start that I know I won't need to re-write in 6 months. Unless of course it needs to be re-written/refactored to accommodate all those customers knocking at my door ;)
That generally means I stay away from the front-end flavor of the week when starting a new app. Don't get me wrong, I myself have used Angular and Vue for a couple of projects but not in the beginning and not for the core product. I don't like the instability and constant changes of a lot of the newer frameworks.
I think the lesson here is use what tools you already know, and are intimately familiar with. There's no reason it takes two years to launch an Angular app, unless you keep updating to use all the latest and greatest features and versions. The same goes for an old workhorse technology like PHP, avoid using the new stuff in favor of proven frameworks and patterns.
Javascript hipster echo chamber: you're not using react [or insert other trendy framework pushed by code schools and tutorial makers]? Product user: does not give a rip about your precious tech stack.
Completely agreed. Here's another way to look at it from an economic perspective:
It's usually best to focus on propping up your differentiation and competitive advantages, going stock with everything else. If you rely on standard components for things that aren't your special sauce, then you get to ride market forces of commoditization which will drive the cost of those standard components towards zero.
Can you build your own backend database in Haskell instead of using Cassandra or PostgreSQL? Yeah, that would probably be really cool and do well on these boards. Then look back at how many hours you spent getting that to just understand simple SQL, and how many customer-facing features that could've been. Is it cooler to build that database than to set up an email auto-mailer? Yes! Special functional algorithms that operate on B-trees are far more exciting than simple state machines that send emails. But the latter is what the customer cares about, so therefore that's what you care about.
One interesting exception to using cutting-edge stuff may be making it easier to hire cutting-edge people.
It doesn't matter how smart you are. The opinion of the market is the only one that matters, and it expresses it in the form of repeat sales.
I want to emphasize this, and expand on it: Your cool tech startup is not about the tech.
You exist to solve a problem.
Sure, you might use your Cool Tech(TM) to solve the problem. But the salient point is that the problem gets solved. Your customers don't give a rats ass if you solve it with automatic hyperparameter selection for LSTMs, or if you solve it with an Excel macro. They just want. Their problem. Solved.
Agreed. It's one thing if the Cool Tech actually gives you a competitive advantage by solving the problem better, easier, with lower costs, faster, more personalized, etc.
Outside of that...it's all about the business. That's why so many successful businesses are built with Ruby and not "benchmark winner of the week" because Ruby tends to deliver on almost all of the business cases around solving problems and growth.
If you're a larger business and planning to deploy at scale to an existing customer base, the business problems tend to change more towards performance and Right Tool for the Job.
I remember when ruby was the hot tech a few years ago, frowned upon by conservative developers. I learnt ruby back then. I'm glad ruby is now recognized as a more mature ecosystem that does things well, even though it is one of the boring technologies now.
Is Ruby/Rails faster now? I built a few simple sites on Rails 2.3 via Passenger, and my God, it was such a performance hog compared to every other web stack I'd ever used. Probably mostly a function of how heavyweight RoR was, but I never got deep enough to figure out what was so slow about it. It may also have been user error, but it seemed like others were bragging about getting it to levels of performance that would be frankly embarrassing on most stacks.
One thing Rails has over, say, Laravel or Django is the JRuby option which has made significant strides in performance in the last 6 months. There's also Truffle Ruby, Graal and Oracle's Substrate VM which all target Ruby performance so my money is on a significant Ruby resurgence later this year by which time Oracle will likely have open-sourced Substrate VM.
Don't get me wrong, I'm a huge Elixir advocate largely because you get the performance and scaling perks of other languages with very close to the development perks of Ruby.
I just get tired of hearing the "but Ruby is slow" drum beats when it's so consistently successful. Scaling web servers is easy. Scaling the database is hard.
Yeah, I was just asking if it had improved. Scaling web servers might be easy, but it adds administrative overhead, and if you don't have big piles of VC money to burn, it bites into budgets that would be better used hiring more people and working on product. And it makes it so you have to waste your time reworking your server structure earlier than you would have to otherwise - suddenly you need a load balancer, a shared session store, etc. When I ran a company, these were very real concerns.
It being successful doesn't excuse its slowness, in my opinion. There are lots of bad products out there that are successful by many metrics. Speed is an important part of making something good, and RoR added significant hurdles to making very fast sites. There are other stacks that don't have that issue that are also successful, but have other downsides.
Anyway, not worth rehashing these old arguments, I just wanted to know if it had improved. Sounds like it has.
There was a time when Ruby was "the cool exotic and unproductive technology". A lot of wheels had to be reinvented (and new ones added) before it became what it is today, there is nothing special about it.
All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.
One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.
It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.
In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.
It really depends on the interaction between the discipline of your team and the failure modes of the tool. A culture of code review which puts a high bar of justification and documentation-for-new-contributors on monkey patching can counteract this failure mode.
Do you code review what each new library does? It doesn't have to be code you wrote to cause problems. And most people treat a library as a black box with inputs and outputs. Which works well in a sane language, but often not ruby.
I would like to add that Excel macros are excellent; If Google Docs spreadsheet functionality were exportable I reckon that many existing startups could be built as a mere UI change on top of that backend.
> You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Unless you are building tools, products, or services for other engineers.
> Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
I'm going to assume that if someone is going into business for themselves then they are planning on having customers. There are ways to show off that don't put your mortgage and credit rating on the line.
> Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
I'm going to assume, this too, is obvious. What I mean is that anyone who has written a fair amount of software has probably already realized this.
What is it that makes people think programmers are a bunch of navel-gazing narcissists that take great pleasure in impressing other programmers? We do, but we're also rather intelligent people.
I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
The specific business advice I have is: learn to be a leader. Take responsibility for outcomes, give ownership to your team, and learn to guide people. If your business grows and takes off you might find you won't have much time to program everything and will have to act more like a guiding hand and lead your team in the mission and trust them to take you all there.
My other advice is: avoid intuition and gut-instincts. Use data: analyze commit history, watch your issue manager, track performance indicators just as much as sales and marketing. A business is always shifting and changing. Rely on data to help you identify trends and make effective decisions. A gut decision should be a last resort.
> I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
It's far easier to fall into a hole of technical debt this way. The extra costs incurred could be too much for your venture to bear. Among all risks new ventures take, this is probably has one of the least cost:benefit ratios.
to expand on this, i'll trot out my little adage again: most startups are marketing problems, not technology problems.
marketing encompasses the 4 P's: product, price, promotion and place. product is literally the finding of the fit between your offering and the market's needs. price is the portion of the value you deliver to the customer that you capture. promotion is finding and providing potential customers with info about why your product is the shizzle. place is how you deliver the product to your customer (e.g., physical store, direct sales, saas, app store, etc.).
build things that support your marketing activities, rather than building tech that you hope you can market.
What you're saying sounds reasonable but I think it is completely wrong.
I strongly believe that startups very rarely fail because they have chosen to build on a particular immature technology. Some fail or stall because they cannot bring themselves to stop redesigning and rebuilding on the next new technology or design philosophy every couple of months.
But these are completely different issues (related by psychology for sure but not by necessity)
My opinion is you should choose what you find coolest and most exciting now and then stick with it!
Of course the technology you choose should have some traction but don't choose technologies of the past! Whatever you choose will be the past soon enough and that is when you must find the strength to stick with it and get on with creating value for users.
I don't think his comment says that they failed because they chose the wrong trendy language. They are failing because they are too concerned about the language and the process rather than the result.
While I don't really agree, I do think that if one intends to work on a side project or a bootstrapped company, they need to do it in a way that is somewhat enjoyable for them.
It requires lots of energy to see these projects through, and it's hard to emit that energy on something that you don't enjoy doing. If using a less common technology is going to get you working on the problem enough to start getting some velocity, that may well be a worthwhile tradeoff (as long as it's not too out there).
The other thing to consider is that while a basic library supplied by a young language may suit your needs when you're starting out, larger ecosystems are likely to have more advanced libraries that have better performance characteristics, support more obscure use cases, etc., which will only become more valuable as one grows.
Since hiring for engineers is so competitive, it is arguable that choosing fancy tech can give an advantage there. It has been done successfully (in a hiring sense)... Twitter pushing Scala, Jet.com on F# are two I can think of.
The downside is it could backfire on who you're able to hire. It could just lure people who will either want to migrate to the next new-and-shiny or just leave quickly.
I think one thing a lot of startups think is that they absolutely have to be able to attract the best and brightest. In 90% of cases, average level programmers can build your product just fine. Unless you are building for enormous scale or your product is using cutting edge technology, you simply don't need a bunch of programmers from the top 1% or even top 10%.
In my company, we hire middle of the pack programmers for a bargain and use commonly known tech stacks.
> you simply don't need a bunch of programmers from the top 1% or even top 10%
Having done some recruiting at a startup last year, even getting the top 50% to reply to an email is a tough proposition. The problem really stems from brand awareness. No one has heard of your startup, so in a sea of "help wanted" postings on Angelist, Stack Overflow or Craigslist or cold emails, it's extremely easy to be ignored.
Using novel technology and getting the word out (as Twitter and Jet.com did), can at least get technical awareness within a motivated subset of engineers who are interested in said new stuff -- and of all skill levels.
That said, Peter Norvig made a pretty good refutation of your core point[1]. Say your initial site was successfully launched by average engineers. If you're not always trying to hire better than the average employee at your company, your team just gets worse over time.
I'm sure he's right when you are building a one percenter company. But my team will likely never grow to a size that it will ever take on a life of its own outside my control. 5 engineers tops when we hit market saturation. Each new hire I make is more skilled than the last because I can pay more as time goes on.
I just don't think research done from the perspective of the biggest tech company in the world has any relevance on 99.9% of small tech startups.
Doesn't this say more about the flaws of the business and/or the management than it indicates this being a good idea? Many of the most successful software companies do everything they can to attract and retain the upper end of software engineers and they don't do this because it's bad for businese. Presumably they do this because it provides more value for the company than having more programmers or trying to save money on salaries/perks.
Perhaps, but I actually think getting the best and brightest is more of a factor of having tons of VC money. In that case, you need to move as fast as possible, and every little bit helps. If you are building a niche business with limited TAM, you just don't need the top tier, assuming of course you aren't building something groundbreaking from a tech perspective.
Interesting perspective. Kind of reminds me of the discussion yesterday about programming contests not being the best indicator of software engineering success. Personally I love programming contests, but reading your comment I can see how it's not the most important thing to be in the top 10% in Algorithms.
Your main focus should always be to ship good user tested product, and I agree you don't have to be the best programmer to build something that users want and like.
Wow, love this article. The context of this article is how I ran my consultancy and the developers didn't enjoy my choices to choose the "boring" tech over what new tech they wanted to bring in, in the middle of a project. "Secrets of Consulting" is a great book if you've never read it, too
I'd like to add: if you find the time, try to have a side-project on your own time where you apply all these cool new things you were looking to apply in your company. This will help you keep your sanity and it will let you experiment with that technology so that you can make a better informed decision on wether to implement it in your company or not.
And yet, 99% of founders out there don't care about building a unicorn. It's just a handful in silicon valley doing anything they can to be the next big thing.
Most entrepreneurs are happy building a good product that helps their customers while making a good living at it.
I'll throw in that this doesn't necessarily mean just use Ruby on Rails and get coding.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.
> Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner.
This is the problem, not Rails. I've been using Rails for years since 2009 without any problems. I've also used PHP, Java, and Node. These projects have survived 5+ years not because of any language or framework but by treating code as a craft.
Ultimately you're in business to convince customers to pay you money in order to use the thing you built. If the code base goes to hell after making customer-requested improvements to the MVP then that's a problem with the design of the MVP code base combined with a lack of refactoring to improve said design. It could be that management didn't want to spend the time or money to rebuild the codebase to let those new features be added in an organized way; that's a management problem. A very experienced developer/lead could translate from nerd to English and from English to Management so the people in charge could understand why they needed to not get new features for three months while the code gets refurbished. If management still says no, because there's no money or they've got impatient customers then that's a different issue.
The specific part of "code as craft" that you need here is a recognition of the value of what chefs call "mise en place". You need to have your work environment in an orderly state that it enables you to work efficiently.
This is true and I totally adhere to it, but, I also think sometimes it's useful to choose the latest and greatest not for the technical aspect, but to attract good devs to work for you.
I don't know. I think there's room for a high-end niche shop that only deals in functional languages, for example. I see enough data now that 1 line of functional = 4 lines of Java/C/Go for the same amount of work done, to think that perhaps, SOME trendy technologies are actually worth their mettle.
I think the real limitation is not jumping on trends but managing cognitive load. That is your real limitation, the capability of the programmer-mind to fathom all the states their code can get in. To optimize towards that, you have to pick technologies that force the least amount of cognitive load on the developer. Functional languages such as http://elixir-lang.org/ seem to accomplish this (according to those who have switched to it and blogged about it, example http://mattscodecave.com/posts/elixir-for-pythonistas-pt1.ht...). In the javascript space, Elm seems to accomplish this. http://elm-lang.org/
But lastly, if you pick the right technology, you might naturally get access to a pool of very high quality developers, the type who are already interested in that very technology.
I don't get the point of hiring "Java people" and whatnot, anyway. Polyglots are the way to go.
The thing that made Paul Graham a thing was his use of Lisp to edge out his competitors at the time. The fact that Viaweb was later rewritten in [whatever it was rewritten in] is irrelevant. That's my final point.
Totally agree with you. In thread of "Linux is obsolete" Ken mentioned the same thing[0] as "...Most users could probably care less if the
internals of the operating system they use is obsolete..." Although, He is talking about OS, but it is true for other as well.
Technology is actually an advantage. I would look at it this way, if you used N tech, and it actually results in a faster, better app, meaning happier users and therefore more business.
Doesn't really give you an advantage if you don't have customers. Even after you have customers, oftentimes the old/boring technology actually results in a faster, better app.
There are always tradeoffs, though. Using technology X instead of technology Y isn't free; maybe there is an additional up front engineering cost, or maybe it's harder to hire devs who know X, or something else. And it's impossible to generalize, of course, but usually the tradeoffs for using superior tech aren't worth it in the short-/medium-term, which is all that matters as a startup.
I don't think you and he are in disagreement. Obviously you should do what will give your business an advantage. He is just saying that it is easy to think that certain new technologies will give you an advantage, but then realize later that what they cost you in bugs/complexity/maintainability etc. make it not worth it for the business. So it's usually better to go with tech that is tried and tested rather than always reaching for the latest new thing.
All the more reason to stick to tried and tested tech. Engineers like to experiment themselves, not have the foundations they stand on be experimental.
I don't think that really answers the question. If your customers are developers, then you need to bring something new to the table or you won't have any customers. You can't sell them someone else's products...
You're talking about two different things. "Technology" in the phrase "don't be seduced by the technology" means, the tech used to build your product. Not the technology of your product itself. Obviously you should innovate when making your product itself, but the tools used to make the product don't need to be bleeding edge for you to do that.
E.g. if you make a website, it should be a unique and engaging website. But you can make a unique and engaging website with Java. Even though it's old tech, your users will not know or care.
I understand what you're saying and totally agree. However, I was under the impression that the parent poster was talking about the products, not the tools, due to the way that it was phrased regarding "foundations".
Our customers are (I work at https://paw.cloud)
For us we are happy with django for backend since we can trust it, but when we do cool stuff with django we take a few days to right up a blog article that for us is direct marketing.
>Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
It could be anything in the top 20, really [0]. The problem is that devs have an impulse to do something experimental and cool, since they have to work with workhorse languages all day at their day jobs.
The myth that they tell themselves is that $REVOLUTIONARY_FEATURE_Y will greatly improve their productivity, but the fact of the matter is usually that no matter how revolutionary the features, it's hard to overcome the benefits that come from an active ecosystem of well-tested and widely used libraries. Even if productivity is improved 20x by the revolutionary feature, a library that has 10 man-years of effort in it will take you 6 months to implement. Rinse and repeat.
This is not to mention the availability of online references and established conventions/best practices, the impact of hitting esoteric errors, and so on.
A good example of this is probably reddit. Originally written in Lisp, they eventually gave up and compromised down to Python due to improved tooling and library availability. [1]
It's just really hard to beat the reliability, community, ecosystem, and features that are table stakes when using a competent web framework.
When you're poking at a new market, you really don't have time to give a shit about writing CSRF middleware. That's one less customer interview or feature request to grow your business. I'm sure you can do it, and no one's doubting your capability to do so. But these are just things that are tricky to implement and takes everyone time and effort to do so correctly.
I have a couple of criticisms of your article. Firstly, you give a list of successful companies who made the "safe choice" you're advocating, but you fail to mention that at the time the companies adopted those projects they were actually the cool, risky new upstarts. Your first example, Twitter, started in 2006 - a mere 18 or so months after Rails 0.8. If Twitter had followed your advice of using a 13 year old web framework when they started, what would they have been using? ColdFusion? They succeeded by using the productive new technology - which at the time (absolutely not now) was Rails.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
I agree with you completely that these frameworks are old. They don't get features like websockets immediately. From a performance standpoint, they are lacking with respect to compiled languages. Statically-typed choices have come a long way.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
Well, I agree with you of course. Re-reading my comment, I overstated my case somewhat. The truth, as always, is somewhere in the middle. I suppose I was reacting to the previous comments as well, asserting that anyone choosing anything other than the boring, tried-and-true mature stacks for any new project whatsoever was being "seduced by technology" and otherwise an irresponsible and non-pragmatic neophilic dilettante who is not a Serious Businessman Like Me.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
> And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
Why? If you're proficient in multiple languages, there's no real upside, especially if each language is easily hireable.
And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)
It's a skill that can be learned like every other skill. You can take the "in 21 days" route or the MOOC / University course route, or constantly read business articles, Steve Jobs videos, etc.
But some top tips stand out for me over time:
* Talking to people, networking > Not talking to people
* Bug free > Elegant code
* UX > UI
* Simple products that do one thing well > Complex products
* Understanding entire market > understanding some people
* Building brand > Making quick money (for the long run)
* Sleep, exercise & healthy food > late night coding
* Solving your problem first > Solving the worlds problems
* Adaptability, pivoting > Ego
* Knowledge of where the money is > No knowledge of it
* Overestimating cost/expenses > Underestimating it
After four years in which I frequently worked in a 6h/1h work/sleep rhythm for weeks at a time, I just left town and decided to never again have any customer that I couldn't fire and forget about on the spot if I wanted.
Big clients and projects were, at least for me, a complete nightmare. Worst were the lawsuits which, even when we ultimately won, would basically ruin whole years at a time.
Now I'm working for a few thousand customers at maybe $50/year average. When some technology or idea seems interesting, I'll spend 48h straight trying to get it working. When the weather starts to get warm, I'll spend the day in the sun with a bottle of white wine and no appointments until November.
Big clients tend to be very slow at signing contracts because their legals would examine every word and will keep asking you to revise the contract. Furtheremore, real big clients tend to be slow at adopting the techology they just bought, so you may not get feedback quick enough to improve your product. Big clients are more likely to argue for discount as they would use "I am big name" as leverage.
This, and sales concentration is a real risk as well. If you have few big customers and even one of them churns, the impact this will have on you is certainly going to be material.
Yes, the strategy for big client is to lock them in for long engagement (like a 3-YR term). Throw in some nice support package, longer trial period, whatever. Since big customers often take months to fully use a product (6-12 months is very common), I wouldn't worry about "oh now I got big name, I need more infrastructure, more money to pay my cloud vendor." It won't for 6-12 months and you probably can keep all the pennies from the big client monthly. If you get a downpayment (say 1-year for a 3-yr term), you get ammunition to grow your team and get more smaller customers.
This. When small shops land their first big client they're always so excited. To me it's like having a stone tied around your neck. Big clients can often be more trouble than they're worth and become a financial risk when they send you packing and you've hired extra people just for their account.
Good advice. Some of these (most?) apply to the business-side founder types as well:
> Simple products that do one thing well > Complex products
It has been my experience that business people constantly make this mistake. They feel a product has to satisfy all needs. The engineers I have met have consistently argued to remove features that are expensive to develop and add little value.
Both of those are anecdotes. Your milage may vary.
2009 post, but still one of my favorite distillations of the issues around b2b customer types. Particular impactful if you read it when you end up going above and beyond with support, feature development, and contract negotiations with both rabbits and whales and you're running out of money.
No you are wrong. In order to get there (build successful brand) you have to take care of your self. With coding marathons, buckets of coffee and fast food (because "I don't have time to cook") you will end up with heart attack before you achieve what you planned.
Not only that but adequate sleep, regular exercise and healthy eating contribute enormously towards healthier cognition. As a developer, I tend to find myself far more productive and successful in a shorter period of time when I am living on the healthy side of things. Everything that is me just works better when I go for a run three days a week, eat clean foods and get in a solid 8 hours of rest a night.
A full time job is a 9-5. Let's say you commute from 8-9 and 5-630. That means you can gym from 645 to 8 (including travel time), eat decently, do some coding, hit bed around 1030, and be sleeping around 11 (so you have enough time in the morning by waking up at 7). Cook on the weekends, code on the weekends, social life Friday and Saturday night...
Do you work more than 40hrs a week? Why? Sounds like you're creating someone else's brand if so.
Let's say you have half of this spare time to work on your side project, that is 3 hours. Excluding weekends, how much time would it take to build a business out of your 15-hours-per-week side project?
Well, typically building a business is a full time job. I'd recommend someone make extra money in their spare time to facilitate a work-break rather than trying to do two "full time" jobs at once.
With exercise, I'm finding cycling to work and lifting weights are effective in terms of time. I spend half an hour of my day getting to work and back - probably about 10 minutes longer than it would take in a car. And with weight lifting, I never do any more than 3 sets of 10. The actual amount of time it takes is short.
This isn't exactly olympian conditioning, but I do notice a benefit and the time investment is low.
The principle is that you have to maintain health.
I think late-night coding is a near-constant because of our brains automatically optimize us onto what pg describes as "the Maker's Schedule". Context switching is anathema to effective coding, so people automatically go to the time when they'll be least-interrupted, which is when the rest of the world is asleep.
You need around 7-8 hrs of sleeping to focus and proper brain functions. Only 3-4% of world people can survive and work perfectly with 4-5 hrs of sleep.
getting 3 solid hours of working on your brand a day is much better than 7 bad ones late at night. Wake up earlier, work at lunch, work immediately when you get home. Late nights are not always necessary.
I don't think it's accurate if you take it at face value. If you genuinely solve the world's problems, that's a better place to be (business-wise) than having solved your own problems.
But trying to solve the world's problems vs. trying to solve your own is another matter. You probably better understand your own problems.
It means: Solving your problem first > Solving others' problems (that don't affect you). The reasoning is that you are an expert in problems that affect you.
If the problem affects the whole world, including yourself, then it falls in the left bucket.
I get some of these, but "don't procrastinate" and "understand the entire market" are kind of ridiculous. You might as well throw "know everything" and "work hard" in there.
I'm a dev who's starting a business and running up against some of this -- for me 'understand the entire market' resonated.
In my case that means knowing the major datapoints about competitors in my space (public vs private companies, who's making/losing money, appannie stats), knowing everything available about cost of user acquisition, and looking at psych studies on user motivations.
These are things I would have benefited from knowing on day 0 but instead only learned after building a prototype that I had to scrap.
If your business is enterprise focused rather than consumer focused, understanding one or two customers is probably good enough for a start.
Seriously. Your proof that you understand a market is only as good as the frequency that your understanding is tested, whether the test is profits or rote knowledge.
This is true for many things. I'm the best developer as long as I don't compare myself to a better developer.
Also, make sure not to confuse understanding your customers with understanding how the industry works.
Some of the craziest and successful startup ideas come from people who don't understand the industry at all and if they had they probably would have never tried to do what they did.
Survivorship bias. Some of the biggest flops also come from people who don't understand the industry at all, and if they had they probably would have never tried to do what they did.
You can't understand your customers if you don't understand their industry. Picking customers is like investing: if you pick a bunch of customers that are not going to win their industry, you won't thrive either.
That may be true, but it isn't a reason not to try. Heck in the process you may learn the industry, just too late for current venture. It is however a reason to be willing to recognise a flop and abandon it for something else.
Yes, but what I'm actually trying to do is cast suspicion on the dichotomy between industry and customers. Industry is not a thing that exists. There are only people, their objectives, their resources, and their problems. Those are the things that need understanding.
I don't think that's what the parent meant: your time is better spent understanding the whole market than a subset, and your time is better spent getting the important trivial thing done now than working on the not-as-important nontrivial thing.
I found out pretty soon that setting up a successful software development business only receives 20-40% of your time developing software.
Business, like developing software, is a strict discipline, and there is a vast amount of knowledge that only comes from experience.
I found myself trying to do everything, until a friend taught me a clever trick:
1) Write down all of the tasks you have to do on a daily, weekly and monthly basis.
2) Write a short paragraph for each task's job description.
3) Write a job application from yourself for each of the jobs.
4) Contemplate why on earth you would ever hire _you_ for the job!
My advice is to work out exactly what tasks there are in running your business that you are not an expert at, such as accounting, sales and marketing, copy writing, etc. and hire people to do those parts for you. You'll see a return in no time... unless you don't... in which case your business model would never work.
For anyone who's interested in more advice like this, your friend's trick almost certainly originates from Michael Gerber's book The E-Myth [Re-visited]. Highly recommended reading for anyone starting a small business.
Scream it in a loud voice, IF YOU BUILD IT, THEY WILL NOT COME!
You are going to have to build it, find them, plead with them, fight their refusals and shove it down their throat.
There are many unknown "unicorns" that currently exist as code. The code is done, there's just no users, because the world doesn't even know it's a thing and those that do know have not being convinced that it's needed.
My opinion, my advice. Forget the code, find the customers/market first.
A software developer with complete code and no customers is just a software developer.
A business person with tons of customers and no software/product is in business.
So decide if you want to be in business or to be a software developer. I suspect that most developers just dream about business as a means of escape from their day to day reality, but secretly don't even want to be in business, they love writing code more than being in business.
On the other hand I've encountered folks who claim to be forming a start up. They've got the name and the logo. They've got the whole pitch ready. They sound enthusiastic and passionate. But... they still have to find a technical person to actually build it. They basically have nothing.
And I often think there are too many people going around spouting wisdom for example about how you _must_ let customers and market demand drive your product design before writing a line of code. It's actually not true. There's plenty of good businesses which are built upon a fairly deep technical idea, which must have required a lot of development work in isolation before it saw the light of day.
...but I agree it's also a trap leading the death of many unknown unicorns.
Having a name, logo, pitch, passionate doesn't equate having customers. Having customers means you know who you are going to sell to, you have gotten commitment in terms of cash or signed contracts that they are going to going to buy your product if you build it.
My favourite was a slide deck pitched to me where they had 9 people on their 'team slide' with not one of them being a technical person. They were trying to build a phone/fax social database to compete with facebook.
>On the other hand I've encountered folks who claim to be forming a start up. They've got the name and the logo. They've got the whole pitch ready. They sound enthusiastic and passionate. But... they still have to find a technical person to actually build it. They basically have nothing.
These people are usually imposters who are asking for things that are totally unrealistic or generating interest for a concept that doesn't make any sense from a technical perspective. They have an idea and assume it can be done.
It's sort of like saying "Let's build a perpetual motion machine." Everyone is really interested in it, because it's a total fantasy. If the idea is practical, it's usually not hard to find someone who will implement it.
As a technical person, you know the limits. That means that when you go out and sell people or kick up interest, it will be for something that's at least plausible.
The frank truth is that software and technical work is relatively cheap. It cannot be the basis of your business because someone can come in and clone your product after you've done the hard work of introducing an innovative product and establishing/educating the market (I know because this happened to my business).
It doesn't matter if the clone is way worse than your product, because people are only looking at the very high level. If the clone can provide the basic functionality 20% of the time as opposed to your 99% of the time, if combined with substantive marketing, that's more than enough to win. Anyone who has done any amount of product research knows that the good products are almost never the most common ones.
Your brand, reputation, and intellectual property are 100x more valuable than any software or technical feat. Consider that Google and Facebook could lock 4 engineers in a closet for a year and come out with almost any software they wanted for around $1 million.
Ask yourself why, then, they pay $1B+ for companies like Whatsapp and Instagram. It's certainly not because it's too complex to figure out photo sharing or text messaging. They want the brand and the users that come with it, and it's that simple. The one thing that is most expensive in business is user attention and loyalty.
There are many apps that dominated app stores and were probably hopeful that they would be bought by Google/Apple and achieve fame and fortune, only to find that in the next iteration of the OS, they had been "NetScaped"; their core functionality baked into the OS either as an extension of an existing app (many souped-up camera and photo effects apps) or as a new bundled app (e.g., Keep).
The most important thing for tech entrepreneurs to understand is that while the technology is important and can give an edge, it is not the main value in your business. The main value will always be the brand and the users that come with it (and, as intimated above, beware of platform vendors, because they will always have the option to divert most of your user base to a first-party clone). Technology is comparatively cheap.
> while the technology is important and can give an edge, it is not the main value in your business.
Going out on a limb here, but I've been searching for a way to define this for a while, but... maybe those aren't tech companies? I'm talking about companies like Snapchat or Uber or AirBnB which, while they do exist as smarphone apps and lean heavily on the Internet, which unarguably involves a lot of technology, but they're brands, and not tech companies. Nothing wrong with that, but there are "tech" companies where the tech is the value... there are just a lot of non-tech "tech" companies, a majority of them B2C.
Companies that are doing things that humanity previously hadn't done are tech companies. Intel, as an early semiconductor company is, at least originally, a tech company. SpaceX's technology is the company. Regardless of who ends up winning, self-driving cars are going derive a lot of value from their technology in the form of patents.
Intel and SpaceX are less vulnerable to competition because it takes hundreds of billions of dollars to compete with them (nonetheless, they do have competitors). This is not the case with anything that's in bootstrap or even VC territory.
In principle, the same concept applies, it's just that it's too expensive for new entrants to come in to those industries, so they mostly don't have to worry about it. It should also be noted that businesses in other industries often attempt to install similar barriers to entry for themselves; suppressing competition is a huge part of remaining the big dog.
I hate to say it, but "tech companies" are "patent companies". If you have a patent on the technology and someone decides that it's not worthwhile to try to work around it, they'll license the patent, or maybe even buy your company if your patent portfolio is strong enough. In terms of an unpatented innovation by itself or actual software, it's not worth much on its own.
SpaceX's technology is not building a >$10B launch backlog and pulling in over $1B in funding. The SpaceX brand and culture are bringing in the right people to build the technology and the right customers to buy it: this path towards success, by definition, started before the technology was complete.
I have seen this advice throughout this thread - "first find customers, and then build it" but I can't seem to understand the following:
1. why will those customers wait for your software?
2. what if you delay launching your software?
3. As a software dev, I've noticed that 90% of the product is built in 10% of the time. However, it's the final 10% that make/break it - how do you account for that (as you have already promised your future customers a product that you have yet to build) ?
When people say, "first find customers, then build it", they mean find people or businesses with problems that they will pay you to solve. With this in mind, your questions have sensible answers:
Customers will wait for your software because their problems are not being addressed in the marketplace.
The consequences of launch delay are that you erode your credibility and allow opportunities for competitors.
You will want customers to start that will work with you closely so that as you continuously deploy your always-working solution, they see benefit with every release. The second highest compliment you can get is "Your product just gets better and better". The highest complement you can get is payment.
I try to think of the "market" as a pond. The customers are the fish. If you manage to catch a few fish, but can't hold on to them because your product isn't ready yet, it's not the end of the world. At that point, you know that some of the fish like your bait, and there are probably more out there who will want it when the product is ready.
1) Build an MVP, and get it to beta.
2) _Then_ get customers to try it out (give them an incentive, such as giving it to them for free). This works well with individuals, or small businesses. Larger company's won't give you the time of day, and you probably want to wait until you have some sort of following before you approach them; or you'll get squashed.
3) Get feedback.
4) Repeat steps 2/3 until your out of beta.
In my experience, finding customers without code works only for specific products. Best of luck trying to find customers for stripe or intercom without any code.
I'm doing half and half. I'm building the core functions first, which is easily demo'd. Then once I get enough interest, then I'll build the app that handles user accounts.
The best advice I've had (and seen applied in practice) is this:
You need to get your company to 10k USD monthly product revenue within three months. If you can't, either the product, target market or team needs to be revised drastically.
It's hard advice to follow, but it will save you a lot of time because you can't wait months and years doing unessential tweaks to the product and marketing, hoping that sales miraculously grow.
It's also useful as a pricing yardstick early on. If you have very few customers, they need to be paying enough that you reach $10k almost immediately. If your product isn't worth that much, then you need to scale out. It's best to figure this out right from the start.
If it feels like you can't do $10k MRR in three months on your own, then you need to find a cofounder who can do it together with you... So it's a good way to calibrate cofounder expectations as well.
This seems really aggressive, especially for bootstrapped companies. My startup took 31 months to hit $10k MRR, and now we're at ~$130k MRR. I'm really glad I didn't quit after three months. I barely even had the product built after three months.
I think that for most people, if they abandon anything that's not already a huge success three months in, they'll just end up bouncing from one thing to the next and never seeing anything through. It's virtually impossible to bootstrap that quickly, and I'd be surprised if many of the big VC-backed startups we've heard of hit that either (certainly not Google or Facebook who weren't even monetizing yet at that point).
I strongly agree. Let's do the math: With a brand new un-proven product with an unproven pricing model, how many customers does it take to get to $10K MRR? In three months, how many qualified leads can you find and reach, and what percentage of those will close? (with an unproven product in an unproven market, 2% is probably a realistic estimate).
Of course there are scenarios where $10K MRR is possible quickly, but there's no way that is what most successful software businesses look like in 3 months.
It's certainly not a hard goal -- I wouldn't pretend that even SaaS businesses are all that similar. (The degree of reassessment after 3 months is up to you, after all.)
It's really a way to frame the product launch by forcing you to ask hard questions about what you're doing. If you don't even see a way for the product to reach $10k/month with a short-term plan, maybe it's a side project rather than a startup? Or maybe the product niche is too vague or unprofitable, and you need to work on that first?
(I can't edit the parent comment anymore, so a clarification: when I wrote "not a hard goal", I meant that the $10k number is just a rough ballpark -- not that the goal would be somehow easy to accomplish.)
Yes, but no thanks to myself. I wasted about a decade being a crap entrepreneur that didn't have such goals. It was easy to rationalize spending time on the work I liked doing under the pretense that I was improving the product's fundamentals. In retrospect, I would have been much better off facing my fears and doing clearly delineated 3-month efforts with revenue targets rather than persisting with products that don't quite work.
I'm still a crap entrepreneur, but I've become slightly better at teaming up with people who can make it happen.
No, but I've been in a startup that got to $10k MRR in under three months after launching the product... And that opened my eyes to what all the talk about the mythical "traction" actually meant.
If it's a side project, that's a different game. A side project doesn't need traction to be successful for its creator.
Yeah, while this may be good advice for some types of markets/businesses/circumstances, there's no way that it's useful as general advice, especially not for side projects or small companies that only need to support one person. Getting that initial traction is the hardest part. Quitting after 3 months is silly.
I don't know how much Atlassian made in its first three months, but they are one of the only bootstrapped tech companies to go public in the last 2 decades. It took them 15 years. While this is not necessarily the fastest path to success, I 100% believe it deserves immense respect. They're one of the biggest success stories in tech as far as I'm concerned.
(Of note, Atlassian has mainly focused on enterprise markets)
I think $10k MRR is a good target. It's basically a limit of ramen profitability for a small team of 2-4 (depending on the family etc. responsibilities of the team), plus a little bit of extra to run the business. When you hit that, it's possible to commit full-time without extra financing and you don't run out of your savings.
From product launch. The point is to launch something that you can imagine selling $10k/month; that you have some kind of plan how to get to that level of sales; and that you'll hold yourself accountable after three months if it fails (and figure out what to do next, not just stick to the thing that wasn't working).
$10k MMR sounds like a lot of money, but it is not. Most people who have never run a business fail to realize how much overhead there is - costs that the business has to pay that isn't labor or obvious materials. If you make a widget from iron it is easy to calculate the cost of the iron in the widget. Did you ever consider how much toilet bowl cleaner is in each widget though, what about your time to clean the toilet? (once you are making more money you pay someone else to clean the toilet, but you still have to account for your time checking that they actually clean it) $10k MMR sounds like a lot, but after overhead I would expect it would give you the equivalent of $50k/year in salary - I think most people reading this make more than that.
To answer your question: The day all your other investment dries up in the worst case. If you have no job or savings you can probably live 3 months on things like your credit cards and not paying the landlord - after those 3 months you better have enough income to start paying your personal debt. That is you need to send the landlord a check for at least 1.5 months rent and with a promise to pay the rest off soon. Likewise you need to be able to buy your groceries with cash and pay down the credit card dept you ran up. It should go without saying that in those 3 months your personal bills should be just enough to stay alive.
Note that the above is the worse case. If you are in month two of the above situation and realize that you won't make the $10kMMR number you should cut your losses, declare bankruptcy and find a day job.
You probably have some savings to live off of though. This means that you have some flexibility. If you are in month 2 and realize you won't make the 10kMMM you can decide if you cut your losses now or not. You have an idea of what your overhead is, who your real competition is and what your leads are (and thus likely future MMR - though don't get over optimistic), if you think things will get better continue, if not cut your losses: you can probably sell to a competitor for a small price and make everyone happy.
If you have investors who are any good at all they have considered your business plan. Sometimes they will insist on the 10kMMR or they will exit, other times they will agree to fund a plan that won't make money for months - but the plan covers that and you have enough income from the investors to live.
There are always other considerations to. 10kMMR is a good number, but you have to figure out how it applies. If your target market is snow plows you should expect your entire income to come during the 3 winter months, and 0 the rest of the year. Thus in winter your MMR needs to be at least 40kMMR, and you need a savings plan of some sort to get through summer.
Don't forget that you can sometimes moonlight. Maybe your ideal is only worth $2kMMR. If you can support this business working only 8 hours a month you keep (or find) a day job for most of your income. That extra 8 hours a month works out to $100/hour after overhead. This again changes the calculations.
Generally speaking, I'd say $10k MRR in three months from a dead start is only really doable if your "product" is in large part a service....e.g., a visualization tool for enterprise customers so they can better understand their data sets (requiring extensive setup and bespoke integrations), or something like that.
I'm sorry but I find this advice deeply misguided. Few startups get to $1k MRR in their first quarter, let alone 10X that. Three months is a good timeframe for a first release and hopefully a few paying customers, but this is unrealistic.
Pitching? I don't know if there's really anything to pitch here. It's the kind of thing I've been told over lunch a few times, and seen happen in practice. That's all.
1) Figure out who you are selling to and what problem you're solving for them BEFORE you build something. It's very easy to fall into a routine of building the best software ever while forgetting you need someone to buy it.
2) Banks will loan you money when you don't need it and won't loan money when you do need it. Apply for a loan or line of credit when you're flush with cash in case of a rainy day.
3) Running a business is a different skill than developing software. Be prepared to learn a lot of new skills.
4) Don't hire too quickly. Payroll + benefits can eat through profits like crazy in a software business. The counter-point is that a good salesperson will bring in far more revenue than they cost in salary and commission.
5) Know your numbers. You should have good accounting records and know from week to week if you are on track or slipping.
6) Don't hire a 'marketing' firm. They will charge 10's of thousands of dollars to ask you questions like 'What do you think we should do?' and then feed it back to you. If the product is positioned well with customers, you know more than the marketing company ever will.
7) Don't let a single customer account for more than 10% of your revenue. If that customer leaves, you'll be in a painful situation. It's difficult to do this at first but it keeps you from chasing a big fish to the detriment of the rest of your business.
8) A good reputation and word-of-mouth is better than buying the #1 spot on Adwords.
9) Figure out how to sell again and again to the same customers. A one time sale makes means a high cost of customer acquisition. Once the customer likes your company you should see what complimentary products and services you can sell too.
10) Once you've had a taste of the freedom (and stress) of working for yourself, it will be very difficult to go back to a regular job and work for anyone else.
> Figure out who you are selling to and what
> problem you're solving for them BEFORE you build something
Prototypes. Powerpoints. Smoke and mirrors. Demos.
Don't build a thing until you have a buyer. A buyer usually is equally happy buying software or watching a powerpoint and buying software that will be delivered in a few months.
Having a customer who has money waiting makes all the other things simpler. Need to rent an office? Tell them you have customers but no money at the moment. They'll figure out a way to get you into that office. Etc.etc.etc.
I was a software engineer for 10 years (first 10 engs at LinkedIn -> first 10,000 at Google -> first 10 at Factual). After that I was about to start a company but fell into venture capital instead. Here are a few things I've learned about business from the VC side that I didn't appreciate very much when I was an engineer:
1) Customers don't care about the technologies you're using, the elegance of your XYZ algorithm, or the novelty of feature ABC. What they care about is solving some problem they have, making their day easier, becoming more productive, etc. When you're pitching your product, talk about how it helps the customer, not about how it's built. A great 5-minute video on this is "Understanding the Job" by Clayton Christensen: https://www.youtube.com/watch?v=f84LymEs67Y
2) Think about monetization early on. Like most engineers, I had dozens of side project and business ideas. For each idea, I had thought about the features I'd build and how I'd build them, but not the business viability: who would I sell to? What would the pricing model be? How much money would that translate to for a typical user? Would users have the work/personal budgets to pay what I wanted to charge? Was the price enough to cover marketing and user acquisition costs? I haven't read it, but have heard that a great book on this topic is Monetizing Innovation (https://www.amazon.com/dp/B01F4DYY1I). Another good book to think about business models is The Art of Profitability (https://www.amazon.com/dp/B000FA5TTM, brief notes: https://codingvc.com/the-art-of-profitability)
3) Finally, think about marketing and customer acquisition in parallel with product. After almost 5 years as a VC, I can readily confirm that most products don't sell themselves. Even the really good products need sales, marketing, etc. A great book to get started on marketing is Traction by Gabriel Weinberg (of DuckDuckGo) and Justin Mares (https://www.amazon.com/gp/aw/d/B00TY3ZOMS/)
If you choose to run a software development agency:
- Shoot for between 3 and 10 clients. Any less and you'll be very stressed about losing a client. Any more and you'll be overwhelmed with juggling too many balls.
- Fire bad clients. They aren't worth the stress, frustration, and opportunity cost.
- Work on your process. Doing an hour of client works earns you one hour of revenue. Improving your agency processes can earn you a large multiple of that.
- Don't be a <insert software technology> shop. Be a solver of a specific business problem for a specific type of business. Example: "We streamline backend processes for multi-million dollar trucking companies." The most valuable contracts are for solving expensive problems.
>Be a solver of a specific business problem for a specific type of business.
Totally agree in principle, but I've found it's very hard to do this in practice.
Unless you have a priori knowledge of an industry, before your first consulting gig in it, it's hard to just step into a business domain and know what specific problems an industry has that can be improved with better software and which of those specific problems are generic enough to be shared by many companies in that industry – while not being served "well enough" by an existing product. And you have to figure out if it's a niche that's big enough to support a company, while balancing other desires, e.g., not spending weeks traveling around the country to sell and work with companies in this sector.
I'm not saying it can't be done. It can, obviously; there are companies doing it. But it's not easy to just go do it. From my limited exposure to consultancies taking this approach, many kind of kept their eyes open and fell sideways into it, i.e., they worked with one client in a sector and realized the client's competitors had similar problems.
Define bad clients. Is it:
1) clients not worth the money for the effort (but good learning), OR
2) clients who are unprofessional i.e. don't pay up etc (I'm sure there are multiple such delineations on what a bad client can be)
There are certain core things that your agency will have to do in order to succeed. Some high level examples:
- Aquire Clients
- Do client work
- Manage projects
- Bill clients
- Do pricing/timeline and estimates
- Hire employees or freelancers
Within each of these high level tasks are numerous subtasks.
You do not want to re-invent how you do those things each time you need to do them. You want a tried a true process that you keep evolving and improving based on a historical success and experimentation. This will allow you to scale and handle larger and larger projects. It will also allow you to onboard new team members quickly and when they leave, the things they learned won't leave with them because you'll have documented the learnings.
This is the book that inspired this line of thinking in me.
We've already established that the main thing to know what makes your customer tick so I'm surprised this isn't mentioned yet:
Your first MVP is simply a static website describing problem, solution and signup, with Google Adwords and analytics.
* Given that your target market are going to be ideally using Google to search their problem or solution, with Adwords, you can test exactly what they are actually searching for when they are looking for your product.
* Analytics will be powerful to measure the engagement of the user to your desired product. Have buttons or measure scroll for engagement. Do they read your problem and leave? Obviously not relevant. Do they continue onto your solution but leave? Wrong market-product fit. Have options on the website for easy A/B testing to figure out your demographic.
* Static website is super easy to change and make pretty as so many templates out there, and even if you don't use A/B testing tools, you note when you make changes, so you can compare sets of user analytics data.
This approach was popularised by lean startup methodologies, but what I love about it is it takes a couple of hours to setup, and an hour each week to tweak and monitor, and you'll know early on whether it's worth even developing the software from the very beginning. The saved time is worth the adwords cost (you can set a budget per day on their dashboard) and cost of static website hosting.
Beware the dangers of the green field. It seems to be every developer's dream to have a green field for a project. You're there at the beginning, so you think you can spend the time to make the correct design decisions early on to ensure you don't end up with the kind of technical debt you've seen at the companies you've worked for before. You'll thoroughly enjoy being a perfectionist, refactoring your code to your own idea of code standard bliss. Immersing yourself in code will keep you busy and make you feel like you are doing important work. The thing is, you're probably not.
Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.
Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".
Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.
Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.
"It seems to be every developer's dream to have a green field for a project."
I've managed at least one developer who was a genius at bug finding and fixing but who was completely lost when given a "green field" part of a the product to work on. I found this out when I "rewarded" him by giving him a "green field" to work on....
1. Your idea and your software will probably not be aligned to your market needs at first;
2. Go out and talk to your customers;
3. Do not just focus on code;
4. When your customer really needs something that is not in your software, do not hesitate to bill this customer for special developments: it will finance the feature for all your customers and keep your feet on the ground;
5. CIO are overstretched by sales rep, so B2B sales cycles can be really long (at least in France).
Disclaimer: CEO of a French Cybersecurity software company.
French market is known to prefer service over software and "On Premise software" over "SaaS". As a result, we switched from SaaS mode to On Premise, and we started with Penetration Testing to join the end of the month.
While my advices might not be the best, we are in our third year of business and should finally reach profitability :)
I have been walking the line between technology (working software engineer my whole career) and business (small business owner, technical cofounder, startup employee several times over) my whole life and if I had one thing that I wish I had known earlier it's this: trust yourself! Just go, learn, and repeat - action is king.
Let me elaborate on that a bit. Seeking more and more knowledge and wisdom in an effort to learn some kind of system or trodden path to success is understandable but can quickly consume all of your time & energy and likely won't provide much real value over the long term. Nothing, and I mean absolutely nothing, beats jumping in, doing stuff, being objective and introspective enough to identify what works and what doesn't, and iterating. What people are doing now will change. What people are using to do those things will change. What won't change, though, is the value of being able to take action and move through that world with confidence and resilience.
Reading, research, and listening to people is good but you should trust the laboratory of action above all else, especially over other people's opinions. Why, if you're a normal, intelligent, rational human being, would you ever put the opinion of some arbitrary person above what you can observe yourself? Because it's on the web or in a book? That's silly. Be extremely selective in who you allow to be your advisors - you wouldn't indiscriminately sleep with just anyone at the drop of a hat, would you? Don't just take advice from everyone, either.
Don't let people pigeonhole you, don't let people project their ideas onto your passion, and learn to identify where you should spend your precious time & attention - most of the time, you should spend those on action, not navel gazing and not "preparation" for action.
There are maybe a handful of books and blog posts that are really worthwhile. Once you have read those, everything else is simply other people regurgitating what they have read and is therefore not very useful. Also, on points that are very crucial, like legal and financial matters, I would hope you have an attorney and accountant to help you make those decisions - don't try to learn everything yourself and carefully establish and nurture your inner circle so that you can focus on - you guessed it - action.
Sure. I like Hello, Startup by Brikman and Zero to One by Thiel and follow Y Combinator's content on YouTube. I also love Disciplined Entrepreneurship - the book used in MIT's Entrepreneurship 101, 102 & 103 courses. There's a corresponding workbook, too. A lot of this stuff is subjective, though. That's the stuff that has proven useful to me, personally, but as always, ymmv! Anything on basic business & economics is probably enough for a smart person with a good head on her shoulders to get going & pick up the rest on the move.
Overall, the number one most valuable skill in my opinion, and the one that I keep coming back to over the years is critical thinking. For that, I love Understanding Arguments, the Philosopher's Toolkit & Ethics Toolkit by Baggini & Fosl, and anything "legal", which sharpens your critical thinking, like Farnsworth's Legal Analyst or even Intro to American Law on Coursera. But those three books on basic reasoning will serve you well for the rest of your life as a business and technical leader.
The number one thing is understanding what customers want. Every business guru and product person in the valley will tell you to "talk to your customers". The major exclusion there is how you talk with customers. Simply asking people how you can improve your product or being more deliberate and saying "what do you want? If I could add any new feature, what would it be?" is wasted time. These questions feel normal and correct, but they'll lead you down the wrong path. What you instead want to figure out is the contextual situation which has lead your current customer or prospect to you. Figure out what that customer wants out of that product _for them_. That's how you start to build great products.
1) make an MVP. minimum viable PRODUCT (not prototype)
2) Pick an idea that you would pay to use (product champion). If you are not the target market, you need to find a product champion who will join your team prior to the MVP creation.
3) Do things that don't scale. don't future proof your MVP, just make it so you can validate that your product has a market beyond your product champion.
4) Create a website for your MVP and make sure you can run it at low/now cost for at least 6 months before you decide to abandon. Marketing is hard and product discovery might be the biggest challenge you face. As long as you have more customers every month you are doing ok.
5) Even if you give your product away for free during MVP/beta, figure out some way that customers who want to pay you can. This is very valuable for determining product fit. if nobody wants to pay, figure out what would make them decide to, and use that for determining how to pivot.
That it takes industry longer than you expected for it to move on to the next new thing.
I made this mistake in 2012 thinking that my product would no longer be wanted by 2016 and so didn't invest in expanding sales. 2017 has arrived and our sales are at an all time high and I have no idea when the market will start to decline. I lost a huge amount of money getting this wrong.
In my defence eveyone else in our industry thought the same thing and made the same mistake.
Regarding your particular circumstances, is it because sequencing centers are slow to upgrade to the newest sequencing technology (probably because the investment in the last-generation is so large)?
No. It is because the next-gen sequencers just don't do what the old sequencers (sanger) do (sequence small regions of DNA at high accuracy). The new machines can sequence a whole genome, but if you only want to look at small part of a genome then there is no replacement for Sanger sequencing.
Another surprising reason is the OEM manufacturer of the instrument (hitachi) basically over engineered the machines and built a tank. The machines just keep running and running.
If I had to pick one piece of advice for software developers looking to jump into entrepreneurship, it is that most companies fail because they build something no one wants. In fact they build it really well.
Thus technical debt, scalability etc. simply don't matter until you iterate your way to solving a problem other people care about. That's much better than solving a problem well, a problem that not enough people have.
Ie. in short, stop engineering software and start figuring out what people actually need. Not just 'nice to have', but a real need that causes real pain. To see if enough people need what you are planning to build - you don't need to built at all, just draw it out, explain it in a doc, and go ask people. You have to really ask them and push beyond their initial "sure yeah, it'd be nice to have". Ask them how they do the task / fulfill the need now. Ask them how much that costs. How much would they pay if you built a better one, etc. Really try to get a "no i don't actually need it" instead of being content with the polite lie of people wanting the product.
Interest does not mean shit, turnover is the only important indicator. The difference to gt somebody to go from excited to hand over money is day and night.
Nobody cares about how cool the code is. Nobody cares about how pretty the application is. Those are side issues, does it solve a problem that people are willing to pay to get solved. Excel solves many problems and people are already paying for it.
Your application/idea is not as unique as you think it is.
Disruption and innovation are words that have little meaning these days, most of the time one is trying to improve a process or business, that does not equate disruption/innovation only improvement. Improvement is a good thing.
There are going to be hard days, acknowledge those. Know that everyone who is trying it on their own has those days. Most people don't show them to the outside world it does not mean they don't have them.
Coming up with the idea is easy. Sustaining the motivation to grind over long periods of time is hard. Entrepreneurship is an internal struggle more than anything else.
If you are working a day job as a programmer (while setting yourself up to go down the startup route), go with contracting as soon as you can, the rates are what you set them at and you should always set them high.
The other advice that has been invaluable to me is NEVER EVER reveal your salary to recruiters. Always state what you want to be paid and go from there. When you reveal what you are earning, you are immediately weakening your negotiating position. This may seem obvious but it would surprise you how many people just go along with their very invasive questioning.
OP is talking about a jump to entrepreneurship. Why would an entrepreneur talk to a recruiter about their salary?
If OP is considering a move to contract software development work, your advice could be relevant to OP not offering his/her hourly contract rate to third party recruiters who ask for it, but most independent contractors have an hourly rate because they know the market for their skills.
Any advice on how to transition from a day programming job to contracting? Any useful resources? Where to find contracting jobs/ through agency or directly approaching clients?
Only just noticed this, I guess if you check your comments you can pick this up at some point.
Best advice is do it early, use your usual job sites (Monster etc.). Resources will depend on your country but the only real administrative hurdle is insurance and taxes so you will need to look up what your country's business rules are. Most people tend to set up as a small limited company or something of that nature and then get the necessary insurance and taxes once you actually land your first contract.
This is excellent advice. As a startup with some extremely talented engineers we build amazing products but if no one knows about it, then you've got a bigger problem.
I can't speak highly enough about http://tractionbook.com/ which I recently came into - it has pragmatic advice on marketing approaches and systems justifying with real data how and why to do what.
It's co-written by the DuckDuckGo founder, and as an engineer who is thoroughly tired of marketing "hackers" who justify expensive campaigns with hand-wavy nonsense, this book changed the way I view marketing in general.
A lot of the reviews are positive about the first 2 chapters, but complain that the remaining chapters lack depth. I would like to own a good marketing book for techies written for this age, but I like to see concrete advise.
This book is great. First few chapters outline the general framework and give you the overview of strategies("traction channels"), and the remaining chapters just explore each strategy in more detail.
Definitely worth buying even for the first two chapters.
SHIP IT. Even when you are embarrassed about it. Ship it and try to sell your ugly baby. If you can't sell it, ask why and iterate on that.
I've seen what happens when you keep the product secret, trying to perfect it before you show it to the world. You'll run out of money making a pretty baby that no one wants.
I agree. I developed a Pinterest-like app around the same year they launched. I even had a perfect domain name for it. Being a perfectionist, I never shipped. I was worried about things like scaling to support tens of thousands of photos, a "similar images" feature, etc. A few years after abandoning the project I discovered Pinterest. ¯\_(ツ)_/¯
* Learn to say "no" to feature requests that don't fit.
* Look after yourself. The body supports the mind and vice versa. Neglecting one is neglecting both.
* Delegate.
* Create a distraction-free environment. Co-working space, public library, converted garage/shed, quiet cafe. Only work from home if it is truly free of distractions & interruptions.
* You can't be an expert in everything. Focus on the value creating activities.
I wish I knew that I could start saving and investing the money I was already earning — and retire while still young. Your odds of success as an entrepreneur are basically zero. (I know some of you are going to do the startup or nights/weekends project anyway and I wish you the best of luck.)
If I knew this I could probably have shaved years off of my FI date.
I assume your software development skills are second to none and you could apply them to any problem.
You won't get anywhere solving any problem.
Find a niche for what you can offer, and only go forwards once you've saturated that niche. For example, find a specific line of business that you're passionate about and approach them. Get a name for yourself and excel.
How to listen to a customer and understand their needs, how to market to those needs, how to convert those leads into contracts, how to bill those customers, how to make them feel valued and show value to them, how to upsell when the contract expires (how to get more value from them).
Learn sales. Mostly because it helps you understand the whole of a business, and will guide any prioritisation of your engineering like nothing else.
It turns out, you really don't need to build a great thing, you just need customers who pay.
mattjaynes nailed it pretty much. On a slightly different spin though on the 'wish you knew vs what you know' my journey was a bit different.
When I came to the Bay Area I knew I wanted to be entrepreneur but I also knew I had a lot of gaps in my understanding. The two big ones were sales and marketing, and the other end production and release. I took positions at established companies (Intel and Sun) to learn what these functions do in "real" companies. I then joined as an early employee a start-up, and learned everything I could about funding and equity and the unique environment of small groups tackling big problems. Then did it again and got to learn about the whole acquisition process, the challenges of taking things public (or not), and learned I still had a huge gap in what MBAs called the 'business model.' I went to work at a company that had an excellent leader and business model at the time (NetApp) and started internalizing what adds value, what doesn't, and what is and what isn't a reasonable way to look at things.
If I had to do it again, I would probably have gotten an MBA while I was at Sun (my second job). While there is a lot to dislike about 'MBA culture' that would have been a faster way to accumulate an understanding of how to evaluate a business to see where it could be improved.
- that it's all going to be worth it in the end (it would have been comforting during those 100-hour-weeks)
- Some of that quick & dirty temporary code would be used for the next 18-19 years.
- I might as well have used PHP instead of Perl. Same (bad, messy) code quality, but even faster development and much easier hiring.
- Costly hardware early on was a waste of money (we outgrew it so fast that a beefy desktop PC would have been a saner investment at that point).
- Managing people is the one thing that you can't "fix" permanently. It's always an uphill battle unless (presumably) you're naturally talented/charismatic/psychopathic.
- don't bother with marketing people, advisors, business consultants early on and don't create product dependencies (e.g. by building a specific version of your product for others). It's not worth it until your product is polished and proven.
- Don't hire people carelessly because you don't want to invest precious time. Don't hire friends/acquaintances unless you've seen them working. Firing people is one of the most difficult tasks.
- Bad things will happen. Don't spend too much time trying to prevent them, or worrying to much. Just make sure you know what your options are when you need to put out fires and manage basic info (don't go searching for your hosting provider's phone number when you need it).
I made the mistake to not focus on the business first. The tech is interesting but priority number one, two and three should be the business. Finding customers and serving them efficiently should be the main focus. Only then think about what tech to use.
If you allow it, your customers won't always pay you the money they owe. Always assume that if you don't have the money, it may never come, and arrange your life around that possibility.
Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..
Where are your customers based? Delinquency has never been an issue for us. In some 25 years we only had one customer not paying us an invoice of USD 1,500 over accumulated revenues of US 30 million, and it was because the customer went bankrupt the month after the invoice (unlucky). However we noticed that US-based customers may delay payments sometimes for months but in Europe they tend to pay on time.
Silicon Valley typically but also the East Coast, and also the mom and pop individuals we used to provide internet service to locally weren't always great at paying. Note that I don't necessarily mean customers won't pay ever (although that's happened many times to us), but rather they will pay randomly, not according to the agreed payment terms, treating you as a free bank to fund their working capital needs; a way to improve their cash flow position when they're being acquired; and on and on.
Most common advice is find a customer and then build...This is like most difficult and could turn out to be time consuming...I would twist it to say..Find a prospect, talk to them and then build...With so many people trying to do stuff or saying they want to..A lot of trust on whether someone will really come back with a software is less...And being first timer very few will pay you....
There are exceptional cases where you might find a customer..But then it turns into a service contract than a product development..
Having a a prospect, a channel for repeat feedback on your MVP could be a good start...and mid way through your dev..start looking to convert prospects into beta and then paying customer..
Spending 6 months just to find a customer and not touching product work isnt a great idea for me...
That is debatable. If you are going from 0 to 1, a lot of times new technology is created. It may not be something revolutionary and ubiquitous like the internet or the wheel, but it may be some form of vertical integration, such as Tesla Cars or the iPhone.
I learned some lessons 5 years ago when my initial plan was to do software development on my own after I quit my job. I have concluded a much more fruitful way to go is to develop your own product in a niche and pursue that. Perhaps even multiple products. There are numerous pitfalls to developing on your own that don't have anything to do with software development. Things like getting paid, dealing with customers, scoping projects, conducting meetings/phone calls, providing dead end quotes, etc. When I quit my day job I also hedged my time by building my own products, as of a year or so ago I washed my hands of all freelance development and focus on my own products.
Probably, the best business advice for software developers
"Solving the problem that frustrates you - may be one of the best ways of finding an idea for your startup". Look at these software developers who acted accordingly before they found success. https://belitsoft.com/php-development-services/saas-ideas-st...
Knowing how to sell/market your product is more important than having a fully functional or carefully engineered product. Nobody will give you money for your (master)piece of software if they don't know what it does or what it's for. Sounds trivial, and yet the better you are at software development, the harder it is to keep in mind.
Just because you are good at something doesn't mean you should be focusing on that thing and leave the rest for later.
My one thing: The software business changes faster than you think, especially when you're young and your frame of reference regarding time is so short. Just when you think you're hitting your stride and the business is cruising, that is when you should be working on your next big thing. If you don't, you're going to find yourself "out of the game" pretty quickly.
"TALK TO REAL CUSTOMER AS SOON AS POSSIBLE"
before I started this Venture. It seems that I have this barrier to reach out to them. For my case, it is architecture and construction industry. With luck + lots of meetings with people in this industry. I found my navigator of this industry, he is now my advisor.
The company is generating 6000 dollar now and 1000 dollar monthly revenue and it is growing.
Some industries have incredibly long sales cycles and you will use up all of your savings and then some getting your first customers.
If I were to do it again I would focus on the creating a solution to the smallest subset of the problem I am solving and trying to sell that. Program that one feature and do not start on the next feature until you have a paying customer for the first one.
Understand that marketing is as important or more important than creating an elegantly coded product. You can have the most amazing product in the world but if no one knows about it or is sold on it, it will never go anywhere.
This can be any method of marketing you want, but you need it and it needs to be effective. The odds of being the exception that does not need it are low.
- Speak only when you know you have something useful to offer. Speaking at meetings just to get a word in can lead to others not paying attention over time due to the lack of useful information that is shared. If you are 100% sure of a subject/fact or you have a very useful thing to add to the conversation then try to get it out in the least amount of words. Others will build trust that anytime you speak it is useful information so they will pay attention and listen.
- Be organized! Many developers have messy desks, cluttered folder structures, and no task lists. Taking time to organize and get a good practice of listing out tasks, place items in correct order, and knowing what your daily plan helps in becoming a better developer and more valuable to a business.
- Tooling! Get useful programs, apps, and utilities to get you more productive. Good spreadsheet application, useful powerpoint templates, and documentation tools are an example of items that will go a long way in business.
I am able to deliver features and fix bugs faster when programming in C#.NET and ASP.NET MVC. I am able to administer MS Windows Server with my eyes closed. SQL Server too. That's why I chose MS technologies for my startup. That's what I know best. Use technology that you know best. You wouldn't use a language you hardly know to write a book. You wouldn't want to experience with a second language. Why on Earth would you want to use a sexy and cool tech that you hardly know?
The most useful piece of software that is used by almost all Software Developers around the world was created using Microsoft.NET -> That piece if software is StackOverflow.com. Microsoft .NET is not a sexy and cool tech. Solving problems is hard enough. Don't make it even harder by chosing technology you hardly know.
- when venting/bitching/complaining, make that clear by saying, "Hey friend, I'm just venting here. <venting> ... </vent>"
- don't run out of money
- don't take money from anyone who can't afford to lose it
- search for ways to delegate & outsource non-essential tasks, but plan on doing them yourself, as you'll find there are somethings you can't offload no matter how much you try
- try to avoid putting yourself in a situation where your business dies if any single person dies/walks/disappears
- assume anything you say to anyone was not correctly heard, and ask them to repeat it back to you
- commit to working in 100% in person, or 100% remotely
- be prepared to have to trust others, and adjust your expectations accordingly
Surprised nobody mentions it. The #1 rule i needed to learn:
> Willingness to pay
Most people see it "charge as much people pay"
But the real lesson here is a different one:
You create a value. The value - costs is profit. Someone along the chain makes this profit. Might be the people you work with, your boss, might be the person sitting at your client looking smart for buying in cheap or your client's boss. Someone does. People are ok to pay as much as long as it's less than the value provided (and comparable to the rest of the market - sidenote: specialization)
Someone makes the money. Stop charging in hours. Charge based on the value. (obviously it should be more than the hour costs otherwise dont take the project)
I'm a software attorney - I negotiate software development, installation, support and licensing, deals, including agile software development, SaaS, PaaS, API agreements, SLAs - you name it. I was also in house counsel for a group of tech startups for five years prior to my current role. Finally, I write software, actively - these days in Node - yes, I know this is an invitation to mockery, which I welcome. All of this is a long-winded introduction to try to say I know a thing or two about this.
tl;dr:
1. The most important thing for developers to understand is the business goal of the software they are delivering.
2. The second most important thing for software developers to understand is how much they cost and their opportunity cost - especially if they are on staff.
To explain in more detail:
1. Software you develop professionally serves a business goal. Engineering decisions should be made in support of this goal - they are, themselves, not the primary motivating force. There are often cases where an engineering decision is a key part of the business offering - e.g., a specification, compliance with a protocol or a law or regulation, performance metric, systems compatibility - but this is still a business point. You are still building software for it to be sold. Part of understanding the business goal of the software is how the client (whether that is your employer or your actual client, if you are an independent developer or studio) actually makes money off of that software or how it fits into their business model. This means that, by and large, while executives are actually very sympathetic to engineering decision - you have to understand that a very large number of engineering decisions (possibly a majority?) are non-responsive to business concerns - i.e., they truly do not care if you go with react as opposed to angular for engineering reasons - but they do care if you tell them that there are more developers out there familiar with angular, they are easier to find and hire, the codebase is more actively maintained, it is less prone to failure, it is more likely to continue to be stable in five years, and it will not cost as much to re-factor the old parts of your production-software to this new platform as opposed to an old platform (NB: this example is made up. I have no idea if it is or is not true, with regard to react v angular). They don't care if one is shinier or newer - unless it has a material impact on the ability of software developers to perform and deliver, or it will have a material impact on the stability, security or performance of the underlying software.
2. Software developers are monstrously expensive. Mind-bogglingly so. And non-technical people have a very, very hard time understanding what you do all day. The many, many attempts to metricize software development - velocity, kanban boards, (god forbid) LoC measurements - are an attempt for non-technical people to try and match cost to output. Please understand that this is well meaning - they do respect what you do, they just do not fully understand it, which is why they have to build these elaborate systems to try and make sense of it. To express this another way - you cost money with every breath you draw, and you are fantastically expensive to keep around. A few months ago I was at a JS meetup here in NYC, where a CTO walked through how much work it took to install bower, grunt and babel into their production stack. He said it took 3-4 senior engineers three months of dedicated time to make this transition. I thought to myself, he must have made a great business case, the business managers must have understood this was necessary for the health of the product, his managers must defer to him without question, or the organization has very loose controls, or some combination of the foregoing, because that is somewhere on the order of 3.5 (persons) * 150 hours (productivity / month) * $125/hr (cost of a senior dev, fully loaded) * 3 months = ~$200,000 worth of work for changes to the stack that were purely internal. The math is crude and very back of the envelope - but consider the opportunity cost - that was senior dev time not being put into feature development, critical bug fixes, or performance optimization - it was purely back-end refactoring. Personally, I have no idea if this investment will turn out to have been worth it - I don't know enough about what it was like to write code in that org before and after these changes - I do know a tiny fraction of JS devs work in es6 - so I am skeptical of the utility of babel at this point, but that may be very shortsighted. What I can say with some certainty, however, having negotiated many, many millions of dollars worth of software development agreements, that this was a major operation, even for an 'internal' client. To put it another way, if you hired outside guns to do this same thing, double the cost. The whole point of this story is realize that, when this was all pitched to the management, who are decidedly not software developers, they had to put tremendous faith in their engineering team that this really large cost was worth it, when I'm sure there was a yard-long list of bugs, features and optimizations that were being de-priotized for this fix that the managers would never actually see, touch or interact with directly. When you are pitching engineering decisions to your clients, you have to make it very expressly clear why it matters for the business case - not just why it matters for the engineering case. You may be right and they may even understand and agree - but in the end, unless the engineering changes are going to have a business impact, it is not a good business decision to invest in them. Please understand - sustainability, security, performance and the happiness of the software development staff are important business considerations - so you can include them in your pitch. But if you just tell a manager that react fiber is better and the way of the future, and you must do a full-stack migration from your static HTML forms to react fiber and it will take 1000 hours of dev time, don't be surprised if you get the stinkeye. Tell them this is an investment in the sustainability of the product and it will mean it will work on more systems, more browsers, work better on mobile and make it easier to hire engineers? You may succeed in your pitch.
The only thing that matter is validating. Don't write code if you can avoid it, try to validate for cheaper. "Will someone use this" can be better answered by calling them first, then build with their feedback.
Haven't seen this mentioned yet, so I thought I'd bring it up.
Communication, communication, communication. I'll say it again, communication.
When it gets time to hiring someone to take over the day to day handling of your clients support needs and/or sales inquiries. I suggest you get someone who is very knowledgable about your product and who is interested in converting every single lead into a sale.
This will mean the difference in your business making money or not.
I'm starting a venture and I have many vendors. I must have spoken to 50 potential vendors across many different markets and there are so many sales and support people who are utterly clueless about their company and product. Who go above and beyond telling a potential customer to pound sand. Sometimes I am speechless in the service that I have had with some companies.
In fact, a few times I've actually had to use the nuclear option, which btw I hate. I've had to find the CEO's email and contact them directly. This always made the difference in the connection.
When I have had to do this, it always it went from the support person detailing reasons why the business can't do "that" and that they supposedly pushed it up the chain or spoken with colleagues and it's just not possible to accept my request.
After emailing directly with the CEO, who then forwards the communication to a senior manager and the issue gets resolved quickly.
In fact, I have a beauty of communication which I may one day publish on Medium. Which outlines the how someone went above and beyond not to win my business. I'll be framing this email in my office for sure!
Other great examples are when I am trying to clarify a question and highlighting something in a faq or a webpage and then I get that url link right back at me with the same quote. As if they are copying and pasting me wording from a support document. Which quickly leads me to believe VA's are handling the support and they immediately lose my interest.
Finally, the best ones are when on the vendors side, the communication goes cold. That they just are not interested in getting back to you. Which I can't understand. I want to give them lots of money!
Don't be one of these companies. One lesson I have learnt in the past. Is that if someone approaches you to make money, don't immediately turn them down. Even if they can't help you right now. They may do in the future and it may be really beneficial to both parties then!
Instead of your 7th new programming language, learn accounting, read annual reports of corporations, write a profit and loss analysis for three years forward (this will be vague, nevertheless spell it out the best you can) and know worst-case scenarios.
Work out simple and efficient ways for rock solid end-user experience. Anticipate lots of time spent with customers.
Help others, friends are the most valuable. Protect your plans in the early phases and be prudent with your capital, prepare for the long term. Do not be afraid in taking risks, patience will pay.
There is no clear cut definition of "business." You have a picture in your head of what you want the future to look like, and "business" is all the actions associated with making it come true, and this can vary dramatically by sector.
Best advice I can think of is to not think generally about what is good strategy, or anything of that sort, but about what makes your product valuable in the lives of the people you hope to make it for.
I have felt identifying your target customer quickly is the most important step in transitioning from developer to business. Target customer definition should be as narrow as possible and you should be able to list them (like atleast a hundred of them in a spread sheet with contact information). This helps you to talk to them, validate the problem, get feedback to your solution and sell it to them.
Before you hire anyone make sure you just can't live without them and then wait longer. Before you hire your first developer read the Mythical Man Month. Yes, it's old, it still applies. And, especially today, try your best to use contractors. And, make sure you have a Work for Hire agreement!
Even if you build something on a "build it and they will come" premise, you are right, and there really is demand, you still have to spend time and money to use it - ie. don't forget to test, measure and allocate time and money towards marketing channels.
Be conscious of your core values. Let them permeate the story you tell, guide your key performance indicators, and become the foundation for your company' culture. When you feel your values are being violated, it may be a sign to take a step back and reflect.
Learn to talk to people.
This leads to networking (and intentional or unintentional marketing).
Talking to people, getting to know them, making an effort to remember and contact them periodically... opens doors in the short and long term.
Relationships, networking and face to face advice matter (a lot). Put the time in to build this up, ideally starting before you've quit your day job and jumped in to building a business.
Why not seduced by technology ? As a engineer we create new technology and try our luck if it makes business. If we compromise on that basic fact, we end up as that one of avg business guy
Not a one thing, but I would suggest reading, or at least skimming, The Ten Day MBA. Really good overview of everything that goes into running a business. It's dated, but mostly just in the case studies.
what is the one thing you wish you knew before starting out ?
I'd like to have been exposed to Steve Blank's works, The Four Steps To The Epiphany and The Startup Owner's Manual sooner. They are BTW, both the same book and not the same book. That is, TSOM is sort of the 2nd edition of TFSTTE, so in that sense they're the same book. But while there is a lot of overlap there's also plenty of material in each book that isn't in the other. So for anybody who is interested, I'd actually encourage you to read both.
Likewise, I would have liked to have been exposed to Jeffrey Thull's selling process, "Diagnostic Business Develoopment", which is described in his book Mastering The Complex Sale, Exceptional Selling and The Prime Solution. I'm a fan of his model and while I can't claim to have empirical proof that it works yet, it feels right somehow.
I would also like to have had the chance to read How To Measure Anything by Douglas Hubbard sooner. It's not a book that's about entrepreneurship, selling, or anything of that nature, but the ideas in the book strike me as broadly applicable to many domains. To give a tl/dr; it's roughly something like "use calibrated probability assessments to generate initial estimates, build a model possibly incorporating nth order effects, and then use a monte carlo simulation to build a probability distribution using the estimates and the model". There's a little bit more to it than that, but that's the gist (as I understand it anyway).
Finally, I'd say that I'd like to have been exposed to the ideas in *The Discipline of Market Leaders" earlier. The core idea in that book is that there are different bases for competition. One (obvious) one is price, and another pretty obvious one is "technical (product) superiority". But the book makes the point that there are other, less obvious ways to compete, like "operational excellence" (basically, running leaner and managing costs/defects, etc. better than the competition) and - my favorite - "customer intimacy". The last one basically means being more knowledgeable about your customer's business, making more tailored solutions, and basically becoming more of a partner than just a vendor. That happens to align well with the whole "Diagnostic Business Development" idea that Jeff Thull pitches, so I think these ideas complement each other well.
Outside of all that, my advice, FWIW, would be to say "you can't learn and understand enough about marketing and sales". Seriously, building technology comes easily to us... doing sales and marketing does not always do so. But I firmly believe that this stuff can be learned, and I think that if you're selling something you're actually passionate about (and if it's something you built, you probably will be) then you can learn to sell it without being a "natural born salesperson". Yeah, maybe some personality types take to selling more easily than others, but I think pretty much anybody can learn to sell to some degree... and in the early days of a startup, unless you're lucky enough to partner with somebody who is a "sales guy" type already, you probably will have to do the initial selling.
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.