Projects

Sunlit Live

Sunlit Live is a caregiving platform focused on helping families and care teams navigate the fragmented work of senior care.The engineering work centered on reducing the operational friction around an early MVP: shortening the path from code to production, removing infrastructure that was adding process without adding proportional value, and making better use of the services already being paid for.

2026 · Founding Engineer · Current project

Visit site

How I contributed

Challenges

A deployment process built for more complexity than the MVP needed
Production deployments typically required 2–3 hours of coordinated team time. Changes moved through multiple environments, with conflicts resolved along the way and repeated environment hopping used in the hope of catching bugs before production.
Infrastructure spend without proportional product value
The stack was paying for multiple services, including GitHub, AWS, and OpenAI, without all of them being used as effectively as they could be. At an early funding stage, unnecessary operational spend directly reduced the time available to build and validate the product.

Role & ownership

  • OwnedDevelopment and deployment workflow redesign around trunk-based development
  • OwnedReduction of the deployment environment footprint from multiple environments to two
  • OwnedOperational changes aimed at reducing release coordination and deployment friction
  • OwnedMigration of AI workloads from direct OpenAI usage to Amazon Bedrock
  • Contributed toInfrastructure and cloud-cost decisions during the MVP stage

Key decisions

  1. 01

    Adopt trunk-based development

    Why
    The existing release process spent 2–3 hours of team time resolving conflicts and moving changes across environments. For an MVP, that coordination cost was slowing down the feedback loop.
    Trade-off
    Fewer environments meant less redundancy in the development path, so the workflow needed to rely more heavily on the quality of the trunk and the deployment process rather than environment-by-environment validation.
    Result
    Deployment time was reduced to roughly 5 minutes.
  2. 02

    Reduce the environment footprint to two

    Why
    The product was still being built and validated as an MVP. Maintaining multiple environments added process and deployment overhead without providing enough additional value to justify it at that stage.
    Trade-off
    The environment strategy was deliberately optimized for the current product stage rather than designed around a future enterprise-scale workflow.
    Result
    The team could move changes through a much shorter path to production.
  3. 03

    Move AI workloads to Amazon Bedrock

    Why
    The existing stack was paying for separate AI infrastructure while already using AWS. Consolidating the AI workload around Bedrock reduced unnecessary service fragmentation.
    Trade-off
    The decision prioritized capital efficiency and operational simplicity during the pre-funding stage over maintaining separate providers for every capability.
    Result
    The change helped reduce spend and extend runway before funding.

Impact

2–3h → ~5m

Deployment time

from coordinated release process to a short, repeatable deployment

Multiple → 2

Environments

a deliberately smaller environment footprint for the MVP stage

What changed

  • The release process was reduced from a 2–3 hour coordination exercise to roughly 5 minutes.
  • Trunk-based development replaced a workflow centered on resolving conflicts across multiple environments.
  • The environment footprint was reduced to two environments while the product was still in MVP validation.
  • AI workloads were moved from direct OpenAI usage to Amazon Bedrock, reducing service fragmentation and helping extend pre-funding runway.

Artifacts

Looking back

The useful engineering decision was not simply introducing trunk-based development or changing AI providers. It was matching the engineering system to the company's stage.

For an MVP, development speed and feedback matter. The workflow therefore favored a short path to production and a smaller infrastructure footprint, while still keeping enough structure to ship reliably.

The same principle applied to infrastructure spend: use the services that create product value, consolidate where it makes sense, and avoid paying for complexity before the product needs it.

Related work