So you want to start a startup? Want to know more about SaaS development?
Ok, that’s cool.
Maybe you have a couple years of marketing experience…
You are awesome on Twitter and can send cheap clicks with Facebook Ads…
You have studied a business related subject and have sculpted a gloriously ambitious business plan…
You are ready to enter the world of tech entrepreneurship…
Except, you can’t code.
But, you have made the decision that your time is better spent elsewhere than either learning to code OR to spend time coding…
You have a brainwave.
Find a technical co-founder!
So you head to a Meetup in your city to network with these “technology” people, but it actually ends up just being full
of non-technical co-founders looking for technical co-founders and the only technical co-founder you spoke to was either disinterested or disinteresting.
You now decide you don’t want to give equity in your immensely valuable business idea away to someone that you don’t know
and have mobilised your savings to invest in paid development. You are now in your “Outsource SaaS Product” development phase.
You head to Upwork and are completely overwhelmed when outsourcers ask you questions like?
“What technology stack do you plan to use?”
“Would you prefer a custom PHP framework?”
Well that is exactly what happened to me.
But luckily I had spent 3 years working on large outsourcing projects in the corporate world, 3 months in a startup
studio in London and had even started my own outsourced service business.
So when it came to outsourcing the build of our first large tech project, we hit the ground running.
And for you?
I will be sharing everything that I learnt from that previous experience AND everything I learnt from this most recent project in this very article.
You will never have to force yourself to go to “networking” Meetups or to considering learning PHP again…
This article will follow the build of Virtual Valley, a Virtual Team Building Platform connecting Entrepreneurs and Rockstar Virtual Team Members (with a time tracking and invoicing software application, the SAAS part ;)) all the way from the idea to testing to the sign off and on-going support.
Now, we won’t be going deep into what makes a good startup idea, as there have been whole books written on the topic.
However I do want to stress the importance of building an idea that has been validated by your target market.
You may be using the BEST outsourcing systems and processes that inevitably will produce an AWESOME product, but if that AWESOME product is not something that people want, you are wasting your time.
Thus the question we must ask before proceeding is:
Yes, this is the seemingly simple, high level question to ask but getting to a reliable answer is complex, so I will hand you over to the masters:
This is the book that inspired The Lean Startup, Steve goes deep into Customer Development, which is the alignment between what you build and what people will use.
We like to think of The Lean Startup as an outlook on life as opposed to a methodology.
- If you throw up a landing page to collect emails before you have a product to test interest – you are being Lean
- If you give your outsourcers a test task before hiring – you are being Lean
- If you scan through a book before you buy it to see if could help you – you are being Lean
When we start building, we will be doing so with a lean/agile process:
And finally, what would your Mom say if you asked her if she would use an iPad cooking app?
Probably yes, because she loves you.
But if you took the “love” from the equation and asked questions with a more tactical approach you may find that your Mom has never actually used her iPad when cooking or would do so if she had one.
This is the Mom Test:
Got an awesome AND validated idea that people actually want?
Specification for a SaaS development
Now, when working for Accenture as a business analyst (building software), we had documents about documents to specify, track and test the software we were building.
We don’t want to do that.
Remember, we are being Lean?
So, the only document that you MUST produce before jumping into the sourcing process for your awesome product is the Requirements Specification Document (or Spec).
A Business Requirement is function that your product must perform to reach a business objective. E.g. for Virtual Valley, Entrepreneurs must be able to Post A Role that they are recruiting for.
This Business Requirement can now be split up into specific User Actions. E.g. for Virtual Valley, in order to Post A Role an Entrepreneur must be able to create an account.
It is important to write your User Actions from the perspective of your user as this will help you sculpt a better user experience for your product.
Each column represents a type of user of your product. E.g. For Virtual Valley we have 4 types of users: Entrepreneur (No Account), Entrepreneur (With Account), Team Member and Admin.
You can mark is BR/User Action as Nice To Have/Must Have.
Shows the status of each BR and the date by which it is scheduled to be closed (by you). Note there are two types of status for each BR: Functionality (does it work?) and Design (does it look right?).
OK, now we have your product Spec’d up, it’s time to move over to those freelancer marketplaces to find someone to build.
My personal favourite of the freelancer marketplaces since the re-design and merge of oDesk and Elance. From our experience they have the largest database of freelancers but lack depth in some technical areas.
Oursourcely saves thousands in commission fees as you don’t pay them a cut when hiring or paying remote workers. Their basic plan starts from $19.
Created by engineers to bring technical talent to the world, Toptal have the best variety and depth of technical expertise in the database though we have found to be the most expensive of the three options.
A less enticing user experience but a good database of technical talent and we have found to be the cheapest option of the three.
Helping people worldwide find jobs and employees for free!
Now, the awesome thing here is that you don’t have to select between the three…
No, once you have created the job post, you can just go ahead, create an account in each, post the job and then sit back to let the quotes roll in.
Here is the job post we used for Virtual Valley:
Ambitious Entrepreneur Seeking Dev Team To Build The Next Upwork/Total/Guru
My name is Tom and I am an entrepreneur looking to hire a development team to build the next Upwork/Total/Guru, we are looking to launch in 6 weeks.
Before responding, please check the Requirements Specification Document here: [[link to Spec in Google Sheet]]
Once you have been through the WHOLE Spec, please respond with the following:
- Rough timelines and quote for “Must Have” and “Nice To Have” features
- A list of links to similar projects
- Why you think you are the best person/team for the role
Thank you and I look forward to hearing from you soon!
Please reply with the word “silver” in the first section of your response so it is clear that you have read this job post in full.
Nice and simple, but note the aspirational and ambitious headline and the spammer check at the bottom.
Each platform will also make you assign a budget for the project, though this doesn’t carry to much weight, it would be good to benchmark your project against other similar projects on the platform to ensure you get the maximum amount of responses.
Now wait for 24 hours then log back in and immediately discard any responses that don’t include the word “silver” in the first line, if they can’t follow that simple instruction what do you think they will be like to build a whole development project with?
Then for those that you think look credible, enter their details in this Google Sheet.
Once you have 20 candidates, schedule a quick 10-minute Skype call to have a general conversation about the project, you are looking to test the following:
- Their communication skills
- How excited they are about the project
- Their understanding of the project
We then took 10 of the 20 candidates from the first interview and invited them to build a more accurate quote on the time and cost required to build out your Specification, this will usually take a couple of days.
Set up a final interview with your top 3-5 candidates and have them take you through their quote and answer any of their questions about your product.
You can then go on to ask a few questions of your own to gage their interest and expertise:
- Are there any other features that we could build that would have a low cost but big impact on our users?
- Are you aware of any competitors in this awesome product?
- What are the major issues you usually face in big development projects?
- Will you be completing the design work or shall I hand that to a third party?
- How will we communicate during the project?
- Will you have a specific project manager?
Quick note on project managers: you need one. But it is up to you who will do this role.
If you have more money than time, you can agree to include a project manager in your Dev Team (if they have one) or if not, you can be the project manager (this is the route we took).
You now should have a good feeling about the partner, which you would like to move forward with.
Though I would make sure you consider the following:
- Do you like them?
- Can you communicate well?
- Do you like their previous work?
- Have they built similar or more complex projects previously?
- Were they reliable with timelines and actions throughout the process?
- Do they have previous clients you can speak to?
- Do their time and cost quote fit within your timelines and budget?
In our case, we went with a team based in Egypt that we got on fantastically well with, had great communication skills and a very reasonable price.
Once you have selected, express thanks to the other candidates and then move to the next stage…
This section is REALLY simple if you decide to work within the confines of the platform, which you found your dev team, which I would highly recommend.
Though you will end up paying a10-15% uplift on the quote, you have payment protect (you can get a refund if things go wrong).
Each team that you encounter should have standard contract they use for development contracts (if they don’t maybe think twice about working with them), here are the things to look out for:
- Ongoing Support : Most Dev Team’s will offer a certain amount of free support for features within your Spec for a period of time after completion, make sure this is clarified.
- Timeline Discounts: You will need to get the Dev Team to commit to the timelines stated by agreeing a reduction in payment if the deadlines are not met by a specific time.
- Spec Timelines/Payments: Ensure that the Dev Team agree to your COMPLETE Spec and the Must Have/Nice To Have features are clarified with the targeted close timelines for each BR and a payment schedule for each milestone (group of BR’s)
- Intellectual Property: I am not a lawyer… But I would advise to ensure the necessary intellectual property clauses exist to ensure that you OWN everything that is built.
- Communication Procedure: Include how you expect to communicate with the Dev Team in the contract. We agreed to have daily check-ins on Skype and a full weekly review of the Spec.
- Code Notes: It is important to agree that the code should contain notes (text not rendered by browser that provide instructions on how the code has been structured) that will guide a new developer you may bring onto the team.
Ok, once you have the above agreed, Skype your new Dev Team, pop a bottle of champagne and explain how happy and excited you are to be working together.
From our experience there are two ways to “manage” a tech product:
- Sit back, relax and get frustrated at the end of the project when your team have built something completely different to your expectations
- Get involved and test/review each requirement as it is developed
No prizes for guessing which we will choose.
Yes, welcome to Agile Development.
You need to be involved with testing and reviewing EACH and every Business Requirement AS it is being built.
Naturally your Dev Team will want to delay showing the client (you) they have polished your work, you need to fight against this by doing the following:
- Make it clear from the start that you need to review each BR as soon as it is built
- When you do review something that is far from complete: DO NOT BE NEGATIVE (This will just delay the time until you can review in the future)
- Always be constructive with your comments
If you are able to adopt a smooth build and testing process using the techniques above, you will find your product coming to life sooner than you imagined.
The next document I introduce you to has the official title of the “Snagging List”, here is a template.
When you complete your testing, do NOT interrupt your Dev Team straight away, instead record it in the “Snagging List” for you to review in your daily calls.
You will note there are two different tabs in the “Snagging List”: one for design (does it look right?) and functionality (does it work?).
With Virtual Valley, we would be notified via Skype of the BR number that was ready to be tested whenever the Dev Team thought it was ready to share (the earlier the better!), we would review, add any comments into the Snagging List and would them pick them up in our daily Skype check in. With any larger issues being moved to the weekly Spec Review calls.
This structured will maximise both your time and that of your Dev Team.
At Virtual Valley, our business model and build moved from being a better-designed clone of Onlinejobs.ph to a fully-fledged Virtual Team Building Platform where Entrepreneurs would actually hire team members through the site.
The point being that almost invariably, the scope of development projects change throughout their lifecycle.
This is the reason for the MASSIVE importance of having a clearly defined Spec in the agreement. So it is clear that when new features are added, the additional cost and time must be added to the schedule.
Importance Of Backups
I would recommend having your Dev Team build your product in your own hosting account AND also to ensure that regular backups are taken.
In our case, we use Hostgator (which take courtesy weekly backups), so when we approached launch day and we foolishly invited an external freelancer into our hosting account to fix a problem with a different business and he proceed to delete ALL of the public.html files in the account we could just load a backup right?
Though it was OUR fault for not ensuring the backups were occurring.
Trust me, you don’t want to be in that situation, TAKE BACKUPS!
User Acceptance Testing
Ok, you and your Dev Team have worked through each and every Business Requirement and have been updating the Snagging List as you go…
You now are reaching the end of the project and your product is coming together, exciting right?
Before you release to the world you want to iron out those last user interface and functionality bugs with some User Acceptance Testing.
This is different from the previous testing of specific Business Requirements once they have been built and tests the user flow between Requirements and the product as a whole.
Luckily, studies have show that up 85% of usability issues can be found by testing with just 5 users, so round up your friend and family and enlist 5 of them to go through your full product and remember, all issues go straight into the Snagging List.
Only once the User Acceptance Testing is complete, the Snagging List is completely closed and you have done a FULL review of the Spec, should you sign off with you Dev Team and make their final payment (previous payments may have been associated with specific milestones).
I would also suggest having one last final meeting to give and receive feedback and to reminisce about the high and lows of your journey, if you a located close to each other geographically, it is always awesome to have this in person.
You should have agreed the support procedures in your agreement so should have an understanding of what your Dev Team have committed to in terms of ongoing support.
Depending on how the project has progressed, you may wish to continue working with your Dev Team on a retainer basis for increased support or product upgrades or you may wish to bring someone on in-house to cover this.
In the case of Virtual Valley, the Dev Team agreed to a year’s support for the BR’s in the Spec and we will continue to put them on a retainer for upgrades in the pipeline.
BONUS For Your “Outsource SaaS Product” Phase
Possibly the most important section of this entire post…
We believe that your ability to work and communicate effectively with your Dev Team is the most crucial factor in the success of your project.
Here is the brief guide:
- Have video calls
- Smile and use smileys
- Ask about them/their first before business
- Never be negative, always constructive
- Explain things multiple times in different ways
- Have them explain complex concepts back you to ensure understanding
Be careful to follow all of the above and you should enjoy a seamless development experience.
You now have the roadmap…
You will no longer need to hard sell that coder you just met in the coffee shop on your idea…
And should be able to build your MVP (Minimum Viable Product, term taken from The Lean Startup) in a matter of months with a few thousand $.
Though now, I need something from you…
If you have a friend that you KNOW is searching fruitlessly for the mythical technical co-founder, please use the share buttons to the right to send this post over, let’s release him from those endless and dull networking events and empower him towards building the best product he can with awesome developers from around the world!
And finally, if you have any questions about the process: tweet me, or drop a comment in the box below and I will get back to you in NO TIME!
(After all, I have to wait until tomorrow morning to meet with my Dev Team about our updated Snagging List, so am sitting here doing nothing ;))