DEV Community: Scott Shoemaker

Sprint One: Slicing the Monolith and Standing Up the Phase A Backend

Scott Shoemaker — Sat, 25 Jul 2026 08:32:44 +0000

Welcome back to the dev log. Last week, Collin and I officially pivoted MedReach AI into a "Data Intelligence First" platform, locking in our enterprise architecture and securing our multi-tenant data models. This week, the planning phase ended. Sprint 1 officially kicked off, marking our transition into active software engineering.

However, as we moved to pull our Phase A (Data Management MVP) tasks from the backlog, we immediately encountered a classic software development trap.

The Problem: The "8-Point Ticket" Trap
As the Scrum Master for this project, my goal is to protect our team’s velocity and prevent burnout. While planning Sprint 1, I noticed several of our backend architectural tickets—such as integrating Microsoft Presidio for PII scrubbing and building our async CMS NPI Registry validation pipeline—were estimated at 8 Story Points.

In Agile development, especially for a two-man capstone team balancing outside lives and careers, an 8-point ticket is functionally a monolith. It represents too much ambiguity. If a single ticket takes 20+ hours to complete, it risks sitting in the "In Progress" column for the entire sprint. If I hit a bug on day two, my velocity flatlines, and worse, I become a bottleneck for my frontend partner who is waiting on that API contract.

Caption: Breaking down our Phase A backlog into highly granular, sprint-ready deliverables.

The Solution: The 4-Point Hard Cap
To solve this, I enforced a strict Agile capacity rule for our board: No single task can exceed 4 Story Points.

We mapped our estimation scale directly to our weekly capacity, where 1 point equals roughly 4 to 5 hours of engineering work. By capping tickets at 4 points, we ensure that the absolute maximum size of any task represents one week of part-time capacity (approx. 20 hours).

I spent the first part of this week slicing our backend monoliths into testable, bite-sized components. For example, instead of one massive ticket for "NPI Validation," we now have separate 2- and 3-point tickets for the base REST connection, the async batching queue, and the local caching layer. This granularity guarantees that even if we hit a roadblock, we can still merge smaller victories and keep the burndown chart moving.

Execution: Architecting the Phase A Backend
With our sprint scope cleanly defined, I swapped my Scrum Master hat for my Backend Architect hat. My primary technical focus this week was our most critical MVP blocker: Security and Ingestion.

JWT Middleware & Multi-Tenant Isolation: Before parsing a single CSV, we had to ensure our data boundaries were airtight. I mapped out and configured the Firebase Authentication middleware to intercept API requests and validate custom Role-Based Access Control (RBAC) claims. This ensures that an Editor in Company A can never access, query, or mutate data belonging to Company B at the database level.
Chunked Ingestion Pipeline: I also began scaffolding the pandas chunked CSV reader. Because enterprise healthcare datasets can be massive, this async ingestion engine is designed to parse large files without maxing out our server's memory, passing the data smoothly to our heuristic column detection logic.

Caption: The MedReach AI Multi-Tenant Isolation & Role-Based Access Control architecture, defining strict database-level boundaries and the permission matrix for our Phase A MVP.

What’s Next?
By slicing our tasks down and securing the gateway, we have created a safe, isolated sandbox to begin heavy data manipulation. Next week, I will be deep-diving into the Microsoft Presidio integration to automate our PII/PHI redaction engine.

Until next time, keep your sprints short and your endpoints secure!

Sprint One: Why We Pivoted MedReach AI to "Data Intelligence First" and Killed the Paid API

Scott Shoemaker — Sun, 19 Jul 2026 15:19:19 +0000

Welcome back to the dev log! If you read my Sprint Zero post, you know my capstone partner, Collin, and I set out to build a full-stack AI platform using an asynchronous, horizontally split workflow. As we transitioned from initial scoping into Month 2 of our build, our concept matured into MedReach AI—a specialized B2B healthcare SaaS platform designed for mid-size pharmaceutical and medical device companies.

However, as we dove into our software architecture review this week, we hit a massive strategic crossroads that forced us to completely refactor our engineering roadmap and Jira backlog.

The Problem: The Insecure "Marketing Automation" Trap
Originally, we visualized MedReach AI as an AI-driven marketing campaign generator that happened to clean Healthcare Professional (HCP) databases. But after evaluating industry pain points, we realized we were solving the wrong problem first.

In the pharmaceutical and medical device sectors, marketing teams don't struggle to generate email copy; they struggle with dirty, unvalidated, and legally hazardous data. Up to 30% of standard HCP databases are riddled with outdated contacts, retired physicians, and unvalidated National Provider Identifier (NPI) numbers. Running automated campaigns on bad data doesn't just waste budget—it creates massive legal exposure under federal regulations like the Physician Payments Sunshine Act and FDA off-label promotion guidelines.

Furthermore, enterprise platforms that actually solve this (like Veeva or IQVIA) cost upwards of $500,000 annually, pricing out two- to three-person marketing teams. From an engineering perspective, treating data cleaning as a simple preprocessing step for a marketing tool was a recipe for disaster. It meant we were treating security, multi-tenant data isolation, and role-based access control (RBAC) as secondary features. In healthcare SaaS, if you bolt on security at the end, your platform is inherently broken.

Caption: Restructuring our Jira backlog into three distinct functional milestones: Data Management, Data Intelligence, and Visualization & Export.

The Solution: A "Data Intelligence First" Architecture
To fix this, Collin and I leaned heavily into our Agile framework and initiated a comprehensive architecture pivot. We repositioned MedReach AI entirely around Data Intelligence, treating campaign generation simply as one of several downstream outputs of a clean, standardized dataset.

To execute this without losing sprint velocity, we made three critical architectural decisions this week:

1. Shifting RBAC and Security to the MVP Blocker
We completely reorganized our 54-task Jira backlog into three new phased milestones: Phase A (Data Management MVP), Phase B (Data Intelligence Alpha), and Phase C (Visualization & Export Beta).
Crucially, we pulled our Firebase Authentication JWT middleware, Firestore database-level multi-tenant security rules, and full-stack RBAC (Admin, Editor, Viewer roles) out of future sprints and pushed them directly into Phase A. Why? Because no file upload or cleaning pipeline should ever be tested without strict tenant isolation already enforcing database boundaries.

2. Killing the Paid API (Why Local Open-Source Wins)
In an era where every startup simply wraps the OpenAI or Anthropic API, we made a deliberate engineering choice: we are using zero paid external LLM APIs.
Instead, our FastAPI backend orchestrates self-hosted Meta Llama 3 8B and Mistral 7B models running locally on an on-premise Ollama runtime. In healthcare, clients are legally and commercially terrified of transmitting Protected Health Information (PHI) or proprietary HCP lists to third-party AI vendors. By keeping 100% of our AI inference inside our own platform infrastructure, we eliminate per-call API costs at scale and turn data privacy into our primary B2B selling point.

Caption: MedReach AI's system architecture, highlighting our self-hosted AI runtime and isolated Firestore multi-tenant data layer.

3. Layering the Tech Stack for Asynchronous Speed
By stabilizing our Phase A core this week, Collin and I can safely maintain our horizontal split. While Collin builds out the React 18 / Tailwind CSS drag-and-drop upload zones and natural language query interfaces on the frontend, I am building the backend Python pipelines. I'm currently integrating Microsoft Presidio for automated PII/PHI detection, scikit-learn for Isolation Forest anomaly detection, and asynchronous HTTP clients to validate provider records against the public CMS NPI Registry in real time.

What This Means for My Journey
As someone aspiring to step into an AI Solutions Program Director or Product Manager role, this week was a masterclass in product framing and technical risk management. It reaffirmed a core lesson: good software architecture isn't just about writing clean code; it's about aligning your database schemas and sprint backlogs with the actual commercial and regulatory realities of your industry.
With our roadmap refactored, our Jira board aligned with our design documentation, and our security gates locked in place, we are ready to build the core cleaning engine.
Next stop: getting our pandas chunked CSV ingestion pipeline and Presidio anonymizers communicating smoothly. Stay tuned for Sprint 2!

Architecting MedReach AI: Solving Data Rot and Regulatory Bottlenecks in Pharma Marketing

Scott Shoemaker — Sun, 12 Jul 2026 16:17:13 +0000

As we kick off Month 1 of our AI Software Development Capstone, I am thrilled to officially introduce the project I will be co-developing over the next five months: MedReach AI.

In my role as the Project/Scrum Master and Backend Architect, I am pairing up with my teammate, Collin Miner, who will be spearheading the frontend UI/UX and client-side architecture. Together, we are building a multi-tenant SaaS platform designed to completely overhaul how pharmaceutical and medical device companies handle outreach, segmentation, and compliance. But before diving into our tech stack, we have to look at why this industry is in desperate need of a modern, lightweight solution.

The Problem: Data Rot and the "Two-Person Marketing Team" Dilemma
Mid-size pharmaceutical and medical device companies face a massive operational bottleneck: their marketing teams run off Healthcare Professional (HCP) databases that are constantly decaying. Industry data shows that physician contact information degrades rapidly—doctors relocate, change specialties, retire, or move across state lines where different data privacy laws apply.

When a two- or three-person marketing department attempts to run a campaign using unvalidated spreadsheets, three critical failures occur:

Wasted Budget & Poor Targeting: Campaigns are sent to outdated contacts or duplicate records, sinking ROI.
Regulatory & Compliance Risks: In the pharma world, sending unverified communications can lead to severe penalties under federal regulations like HIPAA, the Physician Payments Sunshine Act, and strict FDA guidelines regarding off-label promotion.
Resource Drain: Small teams end up spending 80% of their time manually scrubbing CSVs and cross-referencing government registries instead of actually designing marketing campaigns.

While enterprise-grade data hygiene tools exist, they cost hundreds of thousands of dollars annually and require dedicated technical implementation teams—completely pricing out mid-sized organizations.

Sprint Zero: Architecting an Asynchronous Workflow for a Two-Man Dev Team

Scott Shoemaker — Sun, 05 Jul 2026 18:55:51 +0000

Hello World! I’m Scott M. Shoemaker, a Computer Science student with a concentration in Artificial Intelligence, based in Webster, New York. This post marks the official beginning of my Capstone project. However, before a single line of code is written, I had to tackle one of the most critical challenges of software development: project architecture and team management.
The Problem: Scope Creep and Development Bottlenecks
My Capstone team recently pivoted to a two-man structure. My partner, Collin, and I are tasked with building a full-stack GovTech AI application—incorporating React, Python, FastAPI, and PostgreSQL—in just five months. The primary problem we faced this week was logistical: how do two developers, who are also balancing outside careers and lives, build a complex application without constantly blocking each other's progress or causing massive code-merge conflicts?

The Solution: Asynchronous Sprints and API Contracts
To solve this, I leaned on my Agile Project Management and Scrum Master certifications to design a workflow that protects our velocity. Instead of a traditional, intertwined development cycle, I structured our execution plan around a strict asynchronous workflow managed via 2-week sprints.

Our solution utilizes a "horizontal split." I am acting as the Backend Architect and Scrum Master, while Collin owns the Frontend UI/UX. To prevent bottlenecks, the strategy we implemented this week was to define strict API Data Contracts early. By agreeing on the exact JSON format my backend will eventually send, the frontend can be built out using dummy data next month. Meanwhile, I can construct the database and tune the Gemini API in complete isolation. We will not integrate the two halves until Month 3. This isolated sprint strategy mitigates our highest risk and removes development friction.

My Journey and Goals
My journey into computer science has always been driven by a desire to turn chaotic, complex systems into structured, working logic. Beyond this Capstone, my ultimate goal is to step into a role as an AI Solutions Program Director or Product Manager, ideally within the GovTech or AgTech sectors. I want to build practical software that bridges the gap between high-level AI capabilities and real-world utility, translating dense, bureaucratic systems into highly accessible tools.

I’ll be documenting the technical hurdles, AI prompt tuning, and backend breakthroughs of this 5-month journey right here. Stay tuned for Sprint 1!