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.

1. @IZTOK
PROJECT
DATE AUTHOR
02 MAR 2014
DRUPAL AS A LEAN STARTUP PLATFORM
BUILDING MINIMAL VIABLE PRODUCTS WITH A SITE BUILDING APPROACH
BUILD
MeasureLearn

3. 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

4. What is a Lean?
Method for developing
businesses and products
Build-Measure-Learn
Release early, release often
!
Buzzword that got you here :)

5. 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

6. 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)

7. Starting point
Get 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 …

8. 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.

9. Data Structure
Storing 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)

10. Data Structure
Use semantic fields for storing data
• date
• address
• link
• email
• color field
• timezone
• phone number
• file field sources
And many, many, many others…

11. Data Structure
Break data into multiple entities and link them.
Entity reference
Relation
Relation itself is a fieldable entity
Organic groups

12. Relation
dgo.to/relation
Any kind of entities
Store information about the
relation
Advance inherit features
Rules & views support
Video course
Commerce product
Customer
Subscription
Relation
Expiration date
Date field

13. 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)
Company
OG group
Employee
OG member
Project
OG Content
OG Group
Task
OG Content

14. Control the layout
Default block system
not flexible enough
Alternatives
Context
Panels
Working with Node (content)
displays
Display Suite
Panels
Altering forms
Field Group
Display Suite
Panels

15. 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

16. 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

17. Theming
Not necessary if not used as beta release
Look for panels_everywhere supported themes
Bootstrap
IKEA of web design
Warning: dictates the markup

18. 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

19. 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

20. Communication
Sending email with Mandrill (statistics, spam free)
Platform messages
Messages (activity streams)
Private Messages

21. 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)

22. 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

23. GET IN TOUCH
iztok.smolic@agiledrop.com
!
@iztok