I'm a programmer with ten years of experience. I've worked as full time programmer in 2 companies in these ten years as a software developer.

I have always loved to have my own business. My question is, is it ok to start a business project from scratch and write every piece of code from zero?

Remember for example if there are some open source apps close to my project and I prefer to get the source and when the customers come into my business, I start to change program. Not to spend several months and lose the market.

I've seen in companies which I've worked, writing a project from scratch is bad marketing habit and will end to lose all the customers, based on long time of outcome and huge and detailed bugs that comes in.

closed as unclear what you're asking by gnat, Greg Burghardt, amon, mattnz, Doc Brown Sep 30 '18 at 17:34


  • This is an opinion question, right? Most other SE sites turn away from these. But I can't help but ponder over it. What do you mean by lose the market? Can't be a time thing. I'm thinking most business software is older than the machines running it. You mean "someone" will eventually do it cheaper? Then you will always be in trouble. I say it is what you bring to the table. And it is (must be) more than just the SW as all people think some SW is terrible (S.A.P. comes to mind). Then do nothing about it. – st2000 Sep 29 '18 at 13:01
  • @st2000 One of the major things is time.yes.And would you describe SE and SW you used here? – Hamed_gibago Sep 29 '18 at 13:06
  • SE == stackexchange web sites (there are many stackexchange web sites). SW == SoftWare. – st2000 Sep 29 '18 at 13:13
  • Recommended: joelonsoftware.com/2006/04/11/… – Doc Brown Sep 30 '18 at 17:34

What's the value that you want to bring into the market? What can you do better than your competitors?

  • If it's writing software frameworks, then don't hide them in a single-market end product, but make your business from offering that framework to the market.

  • If it's understanding the customer and quickly providing solutions to their needs, re-use whatever suits you appropriate. Don't waste time on writing frameworks.

  • If you have a customer where the out-of-the-box solutions don't fit, and all the other "box-combiner" competitors failed, then do both, the usage-specific framework and the end-user application. The customer will be patient if you can convince him.

  • If all you want to do, is to combine available frameworks built by other groups, then you'll face a hard time against the zillions of competitors who do the same, but have more man-power.

Having said all that, whatever framework / library / components you choose, decide wisely. The fact that a framework has a wonderful whitepaper doesn't tell you anything about the amount of work you have to spend integrating it into your project. Some of the questions can be:

  • How many days would I have to spend for implementing the part that I need, from scratch? If it's just a couple of days, go for your own implementation.
  • Frameworks always have an impact on the code that uses them. Does using the framework improve the quality (readability, robustness, performance, portability, testability, ease of debugging, ...) of your application software?
  • How many days will I have to spend to understand the framework, before I can start using it?
  • How many days will it take to integrate the framework into my project?
  • How buggy is the framework?
  • How good is support and documentation?
  • Will the framework still exist next year?
  • Do new versions of the framework maintain compatibility or do the developers make breaking changes quite often?

Yes, using existing frameworks can help you a lot, and ignoring them is surely wrong, but don't think "using framework = benefit".



It is, if this adds value for the customer. The problem is this is often done just because the developers want a sense of control. They don't like being pushed around by existing code. They don't know how to use the existing code without it taking over.

There is a fascinating TED talk about building a toaster from scratch. It wonderfully illustrates that doing everything yourself is a lot of work to get even tiny things done.

The thing is, that's fine if that's what the customer wants. If you can find someone who values that and will pay for it, fine. If they don't care and just want it today then this is a terrible plan.

What you can do is use isolation techniques like dependency inversion, docker containers, and package managers to wall off the code you write from the frameworks, tools, and libraries you use so that there are isolated places in your code base that neither know nor care about any stuff created by others. Doing this allows you to replace that other stuff with new stuff or even your own stuff when you need to rather then needing to redo everything because a new version of their crap came out.

Doing that will give you all the control you need without having to write everything yourself. If that's all you need then you're set because once you learn how to do this you can still get product out in a timely manner.

If you really want to write everything yourself, just to see if you can, then maybe you should start with very small jobs that are targeted. Microcontrollers put you close to the metal. See if someone needs a custom Hardware Abstraction Layer and will pay you for it.



Yes, if that's what you want to do.

Its not typically the most practical way of doing things, and you may find it helpful to use third party libraries or components to handle functionality that is not a core part of your product. But ultimately its your project/company, so do what you think is best. You don't need anyone's approval.


Is it ok for a business project to start it from scratch and write every piece of code from zero?

No, that's a terrible idea for the reasons you've already identified - you win business by getting your product or service into the marketplace. The way to do that is to use existing tools (whether they be open source or proprietary) where they are the right option and build the bits where there isn't a good option. Otherwise you're going to spend an enormous amount of time and effort building a buggy, less functional replacement for Spring, ASP.NET or whatever else while your competitors have already got your potential customers.

Taking this to extremes, are you going to write your own operating system, your own hardware drivers, your own compilers, and so on? No, because that would be stupid. So given that you're not going to write everything from scratch, don't worry about reusing application level code from other people as well.

  • would you explain the part less functional replacement for Spring, ASP.NET. I'm in this part and I'm writing project in MVC from scratch and I think that there would be open source C# CMS out there like Umbraco that could handle my job with very very less bugs – Hamed_gibago Sep 29 '18 at 13:10

If you like to eat every so often, consider that a metaphor to what will happen to a company with no product to sell over a prolong period of time.

To save time, consider using opensource software, supporting the community by improving it benefiting the opensource community then writing a proprietary shell around it selling this as the value added product.

The recently purchased by Microsoft github.com & the BitBucket offering by Atlassian come to mind as examples of this approach.

  • Can you explain what Microsoft, Atlassian, github.com and bitbucket have in common with a startup creating code from scratch or contributing to open source? – Kasper van den Berg Oct 1 '18 at 14:58
