Also known as: How To Startup.
Below are some of key ideas and strategy on how to build, manage and grow a startup towards an all conquering big corp with big revenue by Sam Altman.
He is the man of Y-Combinator Incubator with impressive line of successful startup. If an incubator has a Dropbox level startup is impressive enough, YC has a line of Dropbox level startup success.
Which means his writing and all is a gold!
If his writing about building a startup has been compiled and edited thoroughly like a guide book and put in one place accessible for all? It is a city of gold!
Said writing entitled Startup Playbook can be accessed here: http://playbook.samaltman.com/
And below are my personal snippets from said post:
- Your goal as a startup is to make something users love. If you do that, then you have to figure out how to get a lot more users.
- It’s much better to first make a product a small number of users love than a product that a large number of users like.
- To have a successful startup, you need: a great idea (including a great market), a great team, a great product, and great execution.
- 3 question to ask:
- What are you building?
- Why are you building it?
- Who desperately need that product?
- The first two is about the idea. It needs to:
- Clear to the founder
- Founder can communicate it clearly
- Simply great
The desperate user is about market. In the best case, you yourself are the target user. In the second best case, you understand the target user extremely well.
If a company already has users, we ask how many and how fast that number is growing. We try to figure out why it’s not growing faster, and we especially try to figure out if users really love the product. Usually this means they’re telling their friends to use the product without prompting from the company. We also ask if the company is generating revenue, and if not, why not.
If the company doesn’t yet have users, we try to figure out the minimum thing to build first to test the hypothesis—i.e., if we work backwards from the perfect experience, we try to figure out what kernel to start with.
- It’s important to let your idea evolve as you get feedback from users.
- We also ask how the company will one day be a monopoly ... Instead, we’re looking for businesses that get more powerful with scale and that are difficult to copy.
- Finally, we ask about the market. We ask how big it is today, how fast it’s growing, and why it’s going to be big in ten years.
- We greatly prefer something new to something derivative. Most really big companies start with something fundamentally new (one acceptable definition of new is 10x better.)
What if you don’t have an idea but want to start a startup? Maybe you shouldn’t. (me goes: HAHAHA!)
...So it’s better not to try too actively to force yourself to come up with startup ideas. Instead, learn about a lot of different things. Practice noticing problems, things that seem inefficient, and major technological shifts. Work on projects you find interesting. Go out of your way to hang around smart, interesting people. At some point, ideas will emerge.
And thats only on Great Idea section of his playbook. There are 3 other bigger section namely Great Team, Great Product and Great Execution.
Please take time to at least go through once his Startup Playbook write up if there is even at least a peanut of ambition in you to build a startup that one day will rule the world.
At least, we will know what we really dealing with.
We will know what we do not know yet. And that is really powerful to us to make informed decision before we even start.
And thank you very Sir Sam Altman. That is really a huge help for us fledgling fellow aspiring founders of yet to born-and-die-repeatedly startup.
The ultimate question that haunt any business or personal that want to outsource website project:
How Much Will It Cost?
Well, here i will try to demystify it once and for all.
This article has two objectives: first, to educate business owner and personnel on web project pricing so that they will get the best of the offer, which is the project is done accordingly.
Yep, that was the most important part. So many web project was dead before it was even born.
Secondly is to educate new web developer, especially the freelancer one on how to do pricing properly. Because most of web project that died prematurely can be traced to developer who quit developing it.
Why they quit? Because the price they charge is really low that they cannot deliver what the clients require.
Hence the importance of good pricing mechanism. It protects both client and developer.
So, the magic formula is:
Web Price = What + When x Who
Yeah, only 3 variable that need to be taken of. Lets visit the first factor: "What"
What To Develop
This factor is the easiest and the most visible part of any pricing structure. But it is the most difficult to pinpoint, and the part that get abused the most by client.
So, please be aware of this.
The idea is simple: the more the requirements, the more it will cost.
However, this is the not so simple part of it: the more COMPLEX the requirement, the more it cost.
Think about it like this: 3 features (A,B,C) will cost 3x, but if you need that features to work together, it need 6x even though it only between 3 features.
Why? Because for A to work with B, you need A-B integration. For B to work with C you need B-C integration and so forth. Which means you need to have:
- Feature A
- Feature B
- Feature C
- Integration A-B
- Integration B-C
- Integration A-C
That is why the more features client ask, the more complex it will be. And the best way to quickly calculate its complexity is by squaring the total features.
3 features will have 3^2 = 9x complexity.
If you have 10 features (well, very common for uneducated client), 10^2 = 100x complexity!
That is why the pricing can get monstrous quickly.
(The right way to calculate it is by using factorial, i.e 10! = 128 million of combination, but i digress.)
Furthermore, not only cost will increase with the increase of complexity, but also delivery time and bugs count. More complex requirements need more time to be developed. Bugs also tend to creep in more the more complexity it has.
And debugging process is the part that both educated clients and experienced developer tend to forget to factor in.
Thus, the rule of thumbs: the simpler the requirements the better!
From experience (mine and friends), the first sign of troublesome project is when the requirement is not been respected enough. Either lack of requirement, incomplete, or none altogether.
Yep, no requirement.
What the F are they thinking?
The bane of developer and project manager is a client who do not know what exactly that they want.
Or they know what they want but they do not want anybody to know. As it will embarassed them or injure their ego.
My advice for the developer: run away quickly from said clients. Too much trouble for so little reward. If there is any reward.
Good developer can consult client on what features to have to achieve and get what said client want. Which means each features and integration in requirements document should have an objective it try to achieve.
By doing that, client can justify their price and project manager can easily write detailed development timeline that both satisfy client requirements AND development capacity.
This bring us to the second factor: When
When Is The Deliveries
This factor at a time can confuse uneducated client. It can be a brain twisted game of 'why?'.
Most of uneducated client will think that the faster the development get done, the cheaper it should get.
This confusion usually stem from the idea that the client is paying for the engineer time. So, the shorter the time the cheaper it gets.
That is a sound logic, but that is why only uneducated clients will jump to that conclusion. As they do not understand first factor that has been discussed above:
Complex Requirement Increase Cost AND Time
In fact, the real reason the cost get higher for complex requirement is that it takes longer time to develop it. Longer time = more it cost.
Thus, the idea for timing and cost relation is: Cost Increase when Due Dates get Unreasonable.
As simple as that.
The shorter the dateline, the more engineer that the developer need to hire to develop all the requirements. The more the engineer = the more it cost.
But as the time get shorter, the cost get lower too. Which will bring back the cost to its original pricing.
What is why make the development shorter will not cut down the price.
Most of client will think : "Well, then might as well we ask unreasonable dateline, as it will not increase the price but we get the deliveries faster. Fast is good!"
However, it is not advisable to just cut short the development time unnecessarily.
Why you may ask. Well, the shorter the dateline, the higher the pressure. Pressure is good to push engineer to develop according to plan. But if the pressure is too high, even the best engineer will stop functioning properly.
The result is: very brittle web application that can get broke down with slightest of pressure to the system.
This is because the first process that will get sacrifice is the 'debugging process'. Debugging is the differentiator between good software and unusable software.
It is not enough to have a functioning software, it needs to be bug-free from general usage by the user. 100% bug free from all fringe cases may not be feasible in the launch date, but the website should not be full of bugs that it irritate the user.
And please bear in mind: the client might not necessarily be the user. In that case, clients need to adhere to real user behaviour and suggestions instead of freely criticises and bring the project to other direction.
Thus for this factor, if clients want their web project to be in proper condition at launch, they need to work hand-in-hand with project manager and developer and not put any unnecessary pressure.
Yes, developer can say they will deliver in time. But the one that get sacrificed is the website quality. It will never be the same as in the requirement.
There is some exception, which bring us to the last factor: Who
Who Is The Developer
Yep, all of this pricing ultimately depends on who was the developer. And please look again that the formula:
Price = What + When x Who
The Who factor is the multiplier. It has the most impact on the formula. In essence we can separate the varaible into two parts:
Price = (What + When) x (Who)
Who will determine your price multiplier for each web project requirements. So, what is the category of developer that you can get in the market?
Lets start from the top: Agency
Web Agency is the largest company you can get to manage your web project. An agency is a company with multiple teams of developer consist of various discipline needed to manage a project successfully.
As it is the largest, it is the most desirable developer from 'make sure the project is done' perspective.
They have the resource in terms of manpower and capital to develop medium and large scale web projects.
However, it is also the highest cost multiplier. Most of project with web agency can easily start at RM 100 000 pricing.
As agency is very capable of delivering various category of project requirements, they are the most flexible with clients objectives. What ever that client want to achieve now, and more importantly: in the future, they can manage to deliver it.
The key point in determining the Who Factor is that short phrase above: 'in the future'.
All of web application project will get changed in the process of developing it. The question is not will it get changed, but how much will it changed in doing any web application project.
Yep, in this field, Change is Inevitable.
That is why clients need to make sure that the developer can factor in future changes in the pricing and development process. If not, then either 1) Do not proceed with the project or 2) Expect frustation in the future.
Any developer that can manage minor changes in project requirement is a good developer.
Which means, the following category of developer does not necessarily sucks compared to above: Development Team.
Development Team is quite rare to be seen. In essence they are the third category of developer (freelance) but get banded together to better serve their client collectively.
We might as well call it The Collective. :-)
DevTeam usually has single project manager that do the meeting part with clients and determine the requirement. Its then get done accordingly by each specialist. Which means DevTeam can have the same capacity and flexibility as Web Agency too.
Price may not necessarily be cheaper that Web Agency, as certain DevTeam hold huge credibility and visibility in the market. However, as rules of thumbs, they can get pretty cheap compared to Web Agency as they did not bear the same costs structure as Web Agency to run their company.
Cheaper than that will be the next category:
Freelancer is everywhere nowadays! In fact, i like to say we have an explosion of freelance especially in web development category. This is a good thing for clients but also a challenge.
It is good as the price for web development by developer in this category is really competetive. It can get as cheap as below RM 1000 price.
However, it does not have its challenge, which is: Credibility of Deliveries.
So many clients get frustrated with freelancer because they did not deliver as per clients desire. This can stem from myriad of factors, not necessarily freelancer lack of skills.
However, with the right freelancer who has enough experience and steadfast in their field expertise clients can get high quality delivery on time. The point of success in this kind of project is communication and due-diligence.
Good project that delivered accordingly always comes down to a good match of client and developer communication style and structure. When client way of doing work is matched with developer, the project is really on the road to success.
Which means clients can have a successful web development project in any of this category of developers.
What matter most is profesionalism in building web application towards success.
Bear in mind that there is 3 important factor that give huge impact to our web application project price. Those factors are:
- What Is The Project Requirements. Complexity will increase cost
- When Is The Deliveries. Shorter timeframe will increase risk and bugs
- Who Is The Developer. Credibility will determine success and cost
Do email me (firstname.lastname@example.org) if you need help in determined your price structure, either as client or as developer.
I'll be glad to help.
Just some small details about me to warm things up.
Call me Robotys, as thats my nick name from primary school. Long story with multiple version of it. I'll tell you when we meet.
Programmer officially since 2008 specifically in web application. Developing web sites of all sorts. Consider myself as fullstack developer. Can do pretty abstract stuff like Web Design and Multimedia all the way down to coding front-end (HTML5/CSS3/JS) and back-end (PHP7) with or without framework (Jquery/CodeIgniter/Laravel).
Currently employed as Senior IT Developer (Web App) at Xentral Methods Sdn Bhd. Managing web assets in form of digital book ecosystem for Malaysia and SEA region. Since 2013, which make it already 4 years!
With that many years under my belt and various scale of project, I also take outside job mainly on consultation and also hands on for selected projects. Usually to help friends and friends of friends on their website needs.
If you like to have a coffee with me on the topics, just PM my facebook. We can arrange a meeting if necessary.
Other than that, i enjoy good books mainly around business topics. Second to that is i like to do marketing experiments and share about it at my personal facebook profile. Its written in Bahasa Melayu mind you. If you like to read about technical and strategic business stuff IN BAHASA MELAYU, then you may enjoy my writing there.
Loosely based in Kuala Lumpur Malaysia. 'Loosely' because i move around 'Greater KL' such as Klang and Seremban and i move alot. Just can't keep my footing down for a long period of time.
This blog is my effort to get back writing in english as i can sense it is withering and getting rusty. So, do advice and help me on it.
Oh, don't let me start on 'speaking' in english. Need so much work there!