I started a large SaaS Company for B2B where perfection in code is as importante as it gets.
So here is my advice, DON'T CODE until you know what the Saas Really is.
First start understanding what the problem REALLY is. Interview people and actually spend 100% of your time doing Customer Discovery. (This sounds easy but it is a skill you'll have to develop far more important than coding).
Once you understand what the problem is, come up with a value proposition. Still no code.
Then make a sell.
If you can actually find things already existing that you can Hack and put it together then use that.
Then make another sell.
If you can sell it to at least 50 people if you are B2C, or if you are B2B you should have at least 1 customer.
Once you do that then start automating some parts of the solution that you have hacked and so on.
But THE most important thing is to be in constant conversations with your customers and hot leads.
Remember you are a customer making machine not a coding machine, the first one is where the money is.
Hope this helped you, if you want to talk more about customer discovery and customer development, just give me a call.
This is a common question for first time founders. Unfortunately, some people misinterpret the Lean Startup Methodology and dive into *coding* an MVP far too quickly.
Rookie founder = (Code —> Design —> Marketing —> [Problem] —> Customer Development ) + only enough cash for one pivot = Quick way to die
Experienced founder = (Customer Development —> Design —> More Customer Development —> Sales —> Code —> More Sales) + cash for 2-3 pivots = Better way to build sustainable company.
Gaining a deep understanding of your customer is the most important first step. See if you can identify a painful and unsolved problem they have, then design a solution and try to sell it. This approach creates demand driven business – as opposed to solution driven – before any code is written.
In my experience, the concept of the MVP is widely misunderstood. MVP’s are not a fully functioning product; they are experiments. Many MVP’s do not involve any code at all. Your MVP might only be a set of mockups done in Balsamiq or Illustrator/InVision.
Learning the Customer Development process is inescapable in today's startup environment. The most helpful resource I’ve found is Steve Blank’s Udacity Course called “How to Build a Startup”. His book "Startup Owner's Manual" is a comprehensive guide through the Lean Startup process, complete with sequential checklists. Both resources are highly recommended.
Link to the video course is here: https://www.udacity.com/course/ep245
I encourage you to not build any code until you have gone through the Udacity videos, started the customer development process, know your customer, and have found people that are willing to pay you for a solution. Code is the most expensive activity to execute, and the hardest to change. When people start begging you for the product, code like there’s no tomorrow!
Happy to share my personal experiences directly with you if you like.
If you got the cash, just hire a few professional coders. Try to focus on your core competencies instead.
You may learn basics of coding, as that will help bridging the gap between you and your engineering team.
I'm a professional coder, feel free to get in touch to discuss the details of your project.
I went through a similar situation, I started building a SaaS product and I only know limited codes.
My advice is focus on what you're good at. Unless what you're trying to build is simple, your time is better off spent building the other aspects than trying to learn to code. I started trying to code myself. But I finally realized that the amount of time it takes for me to write code, I could have made more money, hired a programmer and still have leftover cash and time. Unless you are looking for the learning process then its different.
Even though, I'd advise against writing code, do consider understanding how your programming logic works and what are the milestones. Otherwise you'll have difficulties communicating with developer or managing the process.
Feel free to call me for more details
Jennifer Ping
Founder of Pixall.net
This depends, but first stop for a minute and consider this.
I'm a big believer in bootstrapping. So I always say, do more with less if you can.
Before you even consider coding, maybe you just need to validate your business model first using a lean approach. I would suggest seeing if there is a market for what you want to build: try collect emails, or measure the number of clicks on a site. Plenty of options to build websites and landing pages without ANY coding experience. Then once validated, this question becomes more relevant. If you're there then read on with my answer to your question:
It really depends on if you have a budget or not to hire developers, otherwise you're going to have to give away a large chunk of equity for a co-founding CTO to do the work for you.
It won't hurt to understand the basics of programming to better help with communication either way. This I would recommend. Start with HTML / CSS to get some milage under your belt with something simple. Javascript if you're feeling bold.
Learn to code is continuous, you never stop learning. So make sure you're focusing on your strongest skills. But if money is tight and you can't raise money (which I don't recommend if you don't need to) then try build relationships with developers and see if you can find a match made in heaven and make them your technical co-founder to work with you.
If you want to learn, check out codeacademy.
Hope to see your product soon!
Stefan
You should focus upon your core competency. If you are good at swimming then don't try to climb a tree. For example if a fish try to climb the tree it will fail, similarly if a monkey try to swim it will also fail. Both of them are good in their own fields. In startups we have a simple rule, one builds, one manage and one sells.
All the best.
It is important when it comes to SaaS. One of the main advantages SaaS has over on-premises software is that updates, security and patches, and new features can be released to users in a much easier and more timely fashion. Continuous integration (CI) involves merging all the developer’s working pieces of code into a shared mainline. Once a developer creates a new piece of code and pushes it to the code repository, tests are fired automatically, and the developer is notified if any have failed. This process often happens several times a day.
The aim of a CI environment is to:
1. Eliminate long and risky integrations.
2. Easily and quickly identify bugs and incompatible parts of code, then resolve them.
3. Reduce time spent debugging.
4. Test new pieces of code sooner to determine if they work with the rest of the codebase.
A solid CI environment will allow developers to ensure continuous delivery, which involves continuously releasing new pieces of the software to users.
Coding standards ensure that all team members (developers) follow the same rules when it comes to building software.
The aim of introducing coding standards is to produce code that can be read and understood by all members of the team.
Coding standards cover several aspects, such as name conventions for classes and objects, formatting and indentation, and comments and documentation.
Introducing coding standards brings about the following advantages:
1. The code becomes comprehensible by all team members, which increases the quality of the software and reduces bugs and other issues.
2. Problems and issues can be detected quickly, which results in better efficiency.
3. A more uniform approach to software development and problem solving can be introduced to the team’s workflow, resulting in a faster pace of development.
Introducing coding standards into the team’s workflow is quite easy, as each programming language has its own coding standards and tools.
Even though automated tests significantly reduce the number of bugs and non-compliant parts, it is still important to have the code read by human eyes.
Code reviews occur after the test passes the various assessments that are in place and involves the team members reading each other’s code (a.k.a. peer review).
Code reviews provide the following benefits:
1. Bugs are identified and resolved before being released to the live environment.
2. It enforces developers to write readable code.
3. More experienced developers can identify potential issues and help less experienced developers improve their code.
4. The overall quality of the code increases.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath
Work smarter, not harder. There are plenty of no-code tools out there in the market that lets your bootstrap your company in a matter of days.
