drupal as a lean startup platform
DESCRIPTION
Build. Measure. Learn. This is lean product development in a nutshell. The basic idea is to get a minimal viable product (MVP) out there as soon as possible. Now there are all kinds of MVPs we can build, but for web application we will need to build a working prototype at some point. This session is going to give some tips and tricks on how to use Drupal as a platform I recommend building a prototype upon. Session is also interesting for more experienced developers since I will try to prove a point that rules can be broken during the development of the MVP.TRANSCRIPT
@IZTOK
PROJECT
DATE AUTHOR02 MAR 2014
DRUPAL AS A LEAN STARTUP PLATFORMBUILDING MINIMAL VIABLE PRODUCTS WITH A SITE BUILDING APPROACH
BUILD
MeasureLearn
So who am I?Building/developing with Drupal 6 years
I was involved in 5 web startups in the last couple of years
Failed to show release many own products
Beta-released my first SaaS product PLY.jobs
Reading Lean startup from Eric Ries shifted my mindset
What is a Lean?
Method for developing businesses and products
Build-Measure-Learn
Release early, release often
!
Buzzword that got you here :)
What is a minimal viable product
Anything that can be used to test your hypothesise.
Ad campaign
Smoke bomb
Photoshop mockups
Prototype
More examples:http://to.ly/s70F
Why use Drupal?
“There is a module for that“ (25,000 modules available)
ready to use solutions
open-source (no additional licence costs)
community (access to talent pool, support)
Starting pointGet a couple of days head-start with distributions
Panopoly (best Drupal practices)
MVP Creator (extends Panopoly for startup-ish projects)
Commerce kickstart (shops)
Open Atrium (intranets)
and others …
Don’t code, use modules“There is a module for that.”
Do research, don't pick the first solution/module found by Google.
Go through open issues.
Avoid using modules that don’t use entities and leverage ctools.
Don’t be afraid to use a dev version or even sandbox if done by right people.
Test on a separate built if not sure.
Data StructureStoring data in entities
Preferably nodes (content types)
Best supported by other modules (rules, views, panels etc)
Try to avoid Taxonomy for other that tags and categories
User just as login entity (i.e. separate data-rich profile from user)
Data StructureUse semantic fields for storing data• date
• address
• link
• color field
• timezone
• phone number
• file field sources
And many, many, many others…
Data Structure
Break data into multiple entities and link them.
Entity reference
Relation
Relation itself is a fieldable entity
Organic groups
Relation dgo.to/relation
Any kind of entities
Store information about the relation
Advance inherit features
Rules & views supportVideo course
Commerce product
Customer
Subscription Relation
Expiration date Date field
Organic Groups dgo.to/og
Any kind of entities
Using groups as data hub
Permissions (even field level)
Great ecosystem around OG(add-ons and support)
CompanyOG group
Employee OG member
ProjectOG Content OG Group
TaskOG Content
Control the layoutDefault block system not flexible enough
Alternatives
Context
Panels
Working with Node (content) displays
Display Suite
Panels
Altering forms
Field Group
Display Suite
Panels
Control layouts with Panels dgo.to/panels
Design is not important, layout is
Replacing block layouts with Panels
Using Panels Context and Conditions for logic
Using views content panes inside panels
Custom permissions implementation
Panels Everywhere dgo.to/panels_everywhere
Overriding modules paths/pages (eg node/%node, user/%user)
Selectively choosing variant based on context & conditions
Selectively displaying components based on conditions
Views integration (views panes)
Selection & context for selecting page templates
Complete control over forms
ThemingNot necessary if not used as beta release
Look for panels_everywhere supported themes
Bootstrap
IKEA of web design
Warning: dictates the markup
Codeless business logic dgo.to/rules
Rules module allows site you to define conditionally executed actions based on occurring events
Entities (specially node) fully supported
Add, delete, modify entities or its field based on action
Log events
Permissions checks
Commerce dgo.to/commerce
Eco system of commerce modules
All data stored in entities (extend with fields)
All listing done with views (easy to override)
Logic build with Rules (easy to hook into)
A whole framework inside of Drupal
CommunicationSending email with Mandrill (statistics, spam free)
Platform messages
Messages (activity streams)
Private Messages
Hacking core & modules (aka hurting kittens)
Prototype is not your final product
In some cases you can even get away with bugs
In some cases it doesn’t need to be secure (this goes for prototypes only)
!
Patch modules or even hack them (but document everything because of the team)
Going into production?Shouldn’t be a general rule
Works great for
products with anonymous traffic
low interaction platform
Does not work so well for
Social networks
Real time interactions
