Looking for a downloadable Lean Startup Co-Shoring references? We’ve condensed all of the major points in our blog post, and converted them as a presentation deck.

Published by AB Dev Labs – Startup Development Made Simple. Learn how Co-Shoring can effectively improve Startup Development. Understand the Pros and Cons and Learn the Best Practices for Co-Shoring.

Posted in co-shoring, Lean Startup, Startup Lessons on February 2, 2014   0


Either you love them or hate them. You simply can’t ignore the impact of Apple in modern technology.

In this talk, Author Ken Segall reveals what sets Apple apart from all other technology company – their unwavering principle of Simplicity. Clearly, this belief and process filters down to Apple’s core of product development, design and marketing.



Posted in Startup Lessons on February 1, 2014   0


customer-relationship-management-euroCaribbeanThe success of every startup begins with the customer. No matter how well-written a business plan may be, you never know what will happen when your minimum viable product gets to the first customer. In fact, there’s a 50/50 chance that everything you planned for will change.

The Traditional Route

Basically, for the last 40 years or so, the usual path to a successful business starts with a business plan. You plot everything out in that plan, doing market research and 5 year forecasts, hoping that everything within that manifesto turns out right.

Then when everything is laid out in that plan. You start with product development. Whatever cool idea that you want for your product, you hand it over to the product development team – following the steps of waterfall development to get the product from idea to a real tangible product.

When the product is done. Typically, the marketing and sales team now enter the picture to do what they usually do – find a market, create awareness for the product and hopefully drive value.

Of course, what I’ve just mentioned is a pared down version of the process, but these are the usual key points for companies (and startups) in general.

Though this method works, but there is still a chance for failing.

With startups however, uncertainty is commonplace. Finding that perfect business model that works for your…With this method, the customer research is done prior to launch.

Start with Rule #1 – Start with the Customer

The problem is this, though most startup ideas are good, most startup success stories are attributed to answering a customer’s need – and it just so happened to be technology based. Think of ways on how you can offer Value Proposition. In short, What PROBLEM are you SOLVING? Technology is just a part of the solution, but more importantly, your customers are trying to solve a problem.

Needs are different from problems.

Remember that Your customers do not exist to buy, YOU exist for them.

Posted in Startup Growth, Startup Lessons, Startups on January 31, 2014   0



As I mentioned in my last post on co-shoring, most firms these days are using some form of co-shoring and not even realizng it.  Now a growing group of startups are starting to built with some form of co-shoring. And each option – has its own set of pros and cons such as :

  •  Using staffing sites such as ODeck/99Designs/Freelancer
    • Pros: Easy to find and access, nice tracking software for insuring trust
    • Cons: Transient people,  they are not focused or concerned with your startups needs
  • Complete offshore development firms based in India, South America, Eastern Europe or Asia
    • Pros: A single firm dedicated to your needs, additional resources available if your startup scales or your project needs help, may have common code that can be shared
    • Cons: They are focused on their financial success over your companies / they are encouraged to take on more clients / your engineers are managed not by you and can get pulled onto other projects
  • Local development shops (i.e. the local NYC DevShop) that internally use remote development partners to lower costs
    • Pros: A single firm dedicated to your needs, additional resources available if your startup scales or your project needs help, may have common code that can be shared
    • Cons: They are focused on their financial success over your companies / they are encouraged to take on more clients / your engineers are managed not by you and can get pulled onto other projects
  • 1:1 Engineering individuals located in offshore or out of city locations working directly with your startup
    • Pros: An individual working directly with you
    • Cons: Requires more understanding of technical needs/requirements, requires management

Whatever options startups use, we’re finding that many firms should follow these best practices:

  • Don’t ever bet your entire initial funding on your first MVP – Development is a difficult process, don’t expect the v1.0 of your product to get you there. Surprise can arise in the engineering process. Microsoft Windows Vista took years over the intended development time, and needed a huge “reset” before they were able to release. Airline Planes take off with more fuel then they need to reach their destination, expect the same with any initial product you plan to build from inception.
  • Write a good functional specification – Make sure every last detail is in there. Even if your requirements change, don’t worry your specification can change too. Think of your specification as the living document for your MVP.
  • Make sure all IP is yours – Don’t sign any contracts that make you hostage to ownership of your IP – for most startups, their IP is their single most valuable asset
  • Find engineering partners that are invested in your success and not your checkbook – Many engineering partners refuse to take equity, but that doesn’t mean you shouldn’t look for engineers that are invested in your success. Look for engineers that are willing to put in the extra mile to see your product reach your goal. Ask questions about how they plan for their code to be improved over the lifetime of the product. Ask questions about how they might be involved with your startup after the MVP. If possible try to match your success with their success, such as offering a long-term relationship with your startup, should you succeed.
  • Keep reliable communication – Your remote developer should communicate reliably on a daily basis. We recommend regular SCRUM weekly calls or even daily voice calls with your remote team ensuring they are focused on your tasks. But be careful not to randomize your engineering team with frequent post-MVP tasks and/or BizDev questions. Establish mutually agreeable communication.
  • Document all work – We find Wikis to work well, but make sure that you product can continue being built regardless of who is building it. How does the software get deployed? Write a wiki. What technical debt is present in the MVP? Document this. How do you update the database? Place an article on the Wiki.
  • Get the source code from day one and all code work should be shown daily – A developer should never hold back on the development work on day one. If they are hiding their code, it’s a strong chance that they are behind schedule, working on other projects, wasting time lost in confusion, or delivering low-quality work.
  • Match local engineering partners and domain experts with your offshore team – This probably the crucial point that we argue for in Ab Dev Labs. Find partners who can help review the offshore team’s work and provide you with a in depth understanding of what work is being delivered. If someone is writing code, have another developer local to your startup review it. If someone is designing, have them work with a local designer who may understand your business needs.
  • Set goals and milestones – Make sure to set goals and milestones along the way. Your team should be able to hit milestones and keep their project velocity.
  • Use project/bug tracking software – Use software such as Pivotal Tracker, Github, Asana, Jira or other common tools to ensure that you are tracking all project work in real-time


Posted in co-shoring, Cofounding, Startups on January 19, 2014   0



If you build it, it will come

One of the few long standing startup beliefs is that once you have a cool tech product and a website, people will eventually flock to it, and uber growth happens.  Though, there are probably some exceptions on some startups (ex. Facebook and Instagram) achieving massive growth within a few months of launch, that does not apply to all. The reality is that most startups fail within a few months after launch due to a number of reasons – but the number one reason on that short list is the lack of user growth.


Listed below are the Top 3 Startup Growth Fallacies that most founders believe and do. There’s nothing wrong with having too much optimism – In fact, it’s is a good thing given the nature of this industry.  but if you keep doing the same thing with these 3, then it actually hinders startups from growing.


1. Growth is NOT an ACCIDENT.

As earlier said, there’s this mindset that once a startup is launched, growth is something that happens along the way.  it just happens, and you can’t plan for it.  But in reality, startup growth is planned – it is a scientific process.


2. Growth is NOT an AFTERTHOUGHT.

Now, this comes from a traditional marketing mindset. For instance, once the product is built, management sends it off to  the marketing and sales department to figure out how to attract users – not from day one – on the last minute. The best startups talk about growth from day one – everything is centered on growth – the product is growth centric.


3. Growth is NOT AUTOMATIC

And last startup growth fallacy is that having great technology equals growth.  Again, for most startups – even great products fail – nothing is certain.

Startup Growth is planned from the first day. plus a combination of marketing and selling your product and connecting with customers.  Doing Customer Development early on – ensures that your product will fill a need, and that it solves a customers problem.


In the next post – we will discuss more on the prerequisites that a startup must have to achieve growth.

Posted in Lean Startup, Random, Startup Growth, Startup Lessons, Startups on January 19, 2014   0