OK, so the title starts off a little extreme. Don't scrap your module development just yet (if ever). At the same time, think outside the Drop, and not just on the front end. Inspired by personal experience, a vision of a way forward for Drupal, and this recent article: https://about.gitlab.com/2019/06/17/strategies-microservices-architecture/ - Drupal's oft-overlooked killer feature, and how it can work wonders for getting a startup to MVP or beyond (hint: it has little or nothing to do with content or even Views) - Don't reinvent the wheel - But what if you need wings and wheels? - Or maybe some other vehicular metaphor? - Who's the gatekeeper? (sorry, needed another metaphor) - Is Drupal appropriate for this project at all? {"everyone else at the Drupal event" unsettled Tom meme}
Mike is a software architect and has been a Drupal developer for a decade, a JavaScript developer for nearly two (along with some languages he'd rather forget), with prior backgrounds in IT and design. He presented "Dev/Stage/Prod Parity with Vagrant" at Texas Camp 2016 in Dallas: http://2016.texascamp.org/sites/default/files/slides/DevStageDrop_0.pdf This talk is inspired by his real-world experience with decoupled Drupal in the startup space for quickly getting to MVP and beyond, particularly because it excels at user/role/permission management (around which so many products ultimately revolve), as well as difficult decisions made regarding whether to build microservices or custom modules within a monolithic backend based on per-project timeframe, talent pool, and scaling/future-proofing concerns. He founded Dominant Design & Development in 2018, and co-founded idealFunction() in 2019. He has worked with clients ranging from small businesses and tiny, cash-strapped startups to global nonprofits, corporations, and state and federal government. In addition to building its own SaaS products, idealFunction() helps entrepreneurs who have great product ideas but lack the technical chops or staff to refine and/or architect/develop them.
