The Mission

Build a world where every young person benefits from mental health support

Document Purpose

This document exists to translate the above company mission into a set of concrete deliverables and behaviors that we believe will allow us to make that mission a reality.

This iteration represents a material descoping and shift of priorities in response to changing team size and learnings across the business.

The Thesis

We believe that teens are unable to receive the care they need because they're unable to access care and they and their parents are unaware that they need care. Daybreak succeeds as a business by increasing awareness and reducing barriers to entry without sacrificing quality of care.

To accomplish this we need to ensure that Engineering acts as a force multiplier in everything we do. As an organization Engineering must be nimble yet able to deliver robust technical solutions. We achieve this by making sure our routine tasks are cheap and our system is robust enough that we don't spend our time on unplanned work to keep it up and functioning.

Engineering, as both the developers of our own software and the integrators of our IT infrastructure are the architects and managers of the company’s central nervous system.

The below statements highlight the key things we must accomplish to be nimble enough to support the continued growth of Daybreak and maintain this nervous system.

Updated 2023-04-27 - Combined System Functionality 2024

  1. Daybreak’s infrastructure is primarily a collection of primitives that are orchestrated on a per-feature basis to achieve business or user facing functionality. This allows us to readily configure any mix of functionality for any given set of clients and users. We can think of it as a series of fully independently toggle-able features (and ensuing code silos) sat atop a set of primitives shared across all features.
  2. All records across the entire system can be either Test or Real as defined by the is_test boolean. This boolean has no impact on functionality and merely allows for the labeling of test data in production so that testing is possible across all environments and does not impact real world analytics.
  3. Engineers can easily and quickly spin up new environments, be that locally, or in the cloud.
  4. Engineers are able to provision their development environments with whatever test data they need using a system of well tested data provisioning scripts.
  5. When we hire a clinician, the act of hiring them in Rippling provisions them across the entire system. Their manager and/or supervisor gets a checklist from Rippling for onboarding, meanwhile they’re perfectly setup across zoom, salesforce, rails, etc with no further provisioning work from day one.
  6. When we onboard a patient, regardless of where from, intake & matching run entirely in salesforce. Salesforce guides whomever is executing the process through a contextually aware set of buttons and choices. Once matching is complete, a single button configures everything across the full app that the patient needs, right down to sending welcome emails and kicking off any ongoing management processes for CST or the assigned clinician.
  7. Sales is empowered to operate at scale and with relative autonomy through a Configure, Price & Quote tool that is configured by Product and Management to establish and enforce feature / service availability and pricing requirements.
  8. The Sales to Account Management handoff is enabled and automated through the Configure, Price & Quote tool with automation provisioning the client with all sold features & toggles and kicking off all downstream AM projects via Jira or associated project management tool.