578 lines
18 KiB
Markdown
578 lines
18 KiB
Markdown
---
|
|
title: "Pharma Lab Digital MVP - From Zero to Production"
|
|
slug: "pharma-digital-transformation"
|
|
summary: "Squad leadership in greenfield project for pharmaceutical lab, building digital platform MVP with complex integrations (Salesforce, Twilio, official APIs) starting from absolute zero - no Git, no servers, no infrastructure."
|
|
client: "Pharmaceutical Laboratory"
|
|
industry: "Pharmaceutical & Healthcare"
|
|
timeline: "4 months (2-month planned delay)"
|
|
role: "Tech Lead & Solution Architect"
|
|
image: ""
|
|
tags:
|
|
- MVP
|
|
- Digital Transformation
|
|
- .NET
|
|
- React
|
|
- Next.js
|
|
- Salesforce
|
|
- Twilio
|
|
- SQL Server
|
|
- Tech Lead
|
|
- Greenfield
|
|
featured: true
|
|
order: 3
|
|
date: 2023-03-01
|
|
seo_title: "Pharma Digital MVP - Digital Transformation from Scratch"
|
|
seo_description: "Case study of building digital MVP for pharmaceutical lab from scratch: no Git, no infrastructure, with complex integrations and successful delivery."
|
|
seo_keywords: "MVP, digital transformation, pharma, .NET, React, Next.js, Salesforce, greenfield project, tech lead"
|
|
---
|
|
|
|
## Overview
|
|
|
|
Pharmaceutical laboratory at the **beginning of digital transformation** hires consulting firm to build discount platform for prescribing physicians, starting from WordPress prototype.
|
|
|
|
**Unique challenge:** Start greenfield project in company **without basic development infrastructure** - no Git, no provisioned servers, no defined processes.
|
|
|
|
**Context:** Project executed in multi-squad environment. **Successful production delivery** despite initial infrastructure challenges, with controlled 2-month delay.
|
|
|
|
---
|
|
|
|
## Challenge
|
|
|
|
### Digital Transformation... Starting from Absolute Zero
|
|
|
|
**Company initial state (2023):**
|
|
|
|
**No Git/versioning**
|
|
- Code only on local machines
|
|
- Non-existent history
|
|
- Impossible collaboration
|
|
|
|
**No provisioned servers**
|
|
- Non-existent development environment
|
|
- Staging not configured
|
|
- Production not prepared
|
|
|
|
**No development processes**
|
|
- No CI/CD
|
|
- No code review
|
|
- No structured task management
|
|
|
|
**No experienced internal technical team**
|
|
- Team unfamiliar with modern stacks
|
|
- First contact with React, REST APIs
|
|
- Inexperience with complex integrations
|
|
|
|
**Technical starting point:**
|
|
- Functional prototype in **WordPress**
|
|
- Content and texts already approved
|
|
- UX/UI defined
|
|
- Business rules documented (partially)
|
|
|
|
---
|
|
|
|
### Required Complex Integrations
|
|
|
|
The MVP needed to integrate with multiple external systems:
|
|
|
|
1. **Salesforce** - Discount order registration
|
|
2. **Twilio** - SMS for login validation (2FA)
|
|
3. **Official physician API** - CRM validation + professional data
|
|
4. **Interplayers** - Discount record sending by CPF
|
|
5. **WordPress** - Content reading (headless CMS)
|
|
6. **SQL Server** - Data persistence
|
|
|
|
**Additional complexity:**
|
|
- Different credentials/environments per integration
|
|
- Varying SLAs (Twilio critical, WordPress tolerant)
|
|
- Provider-specific error handling
|
|
- LGPD compliance (sensitive physician data)
|
|
|
|
---
|
|
|
|
## Solution Architecture
|
|
|
|
### Strategy: Start Small, Build Solid
|
|
|
|
**Initial decision:** Explain to the team the process we would follow, establishing foundations before coding.
|
|
|
|
### Phase 1: Basic Infrastructure Setup (Weeks 1-2)
|
|
|
|
Even without provisioned servers, I started essential setup:
|
|
|
|
**Git & Versioning:**
|
|
```bash
|
|
# Structured repository from day 1
|
|
git init
|
|
git flow init # Defined branch strategy
|
|
|
|
# Monorepo structure
|
|
/
|
|
├── frontend/ # Next.js + React
|
|
├── backend/ # .NET APIs
|
|
├── cms-adapter/ # WordPress integration
|
|
└── docs/ # Architecture and ADRs
|
|
```
|
|
|
|
**Process explained to team:**
|
|
1. Everything in Git (atomic commits, descriptive messages)
|
|
2. Feature branches (never commit directly to main)
|
|
3. Mandatory code review (2 approvals)
|
|
4. CI/CD prepared (for when servers are ready)
|
|
|
|
**Local environments first:**
|
|
- Docker Compose for local development
|
|
- External API mocks (until credentials arrive)
|
|
- Local SQL Server with data seeds
|
|
|
|
---
|
|
|
|
### Phase 2: Modern & Decoupled Architecture
|
|
|
|
```
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ FRONTEND (Next.js + React) │
|
|
│ - SSR for SEO │
|
|
│ - Client-side for interactivity │
|
|
│ - API consumption │
|
|
└────────────┬────────────────────────────────────────┘
|
|
│
|
|
▼
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ BACKEND APIs (.NET 7) │
|
|
│ - REST APIs │
|
|
│ - Authentication/Authorization │
|
|
│ - Business logic │
|
|
│ - Orchestration layer │
|
|
└────┬────┬────┬────┬────┬─────────────────────────┬──┘
|
|
│ │ │ │ │ │
|
|
▼ ▼ ▼ ▼ ▼ ▼
|
|
┌────────┐ ┌──────┐ ┌──────┐ ┌────────┐ ┌────────┐ ┌──────────┐
|
|
│Salesf. │ │Twilio│ │CRM │ │Interpl.│ │WordPr. │ │SQL Server│
|
|
│ │ │ │ │API │ │ │ │(CMS) │ │ │
|
|
└────────┘ └──────┘ └──────┘ └────────┘ └────────┘ └──────────┘
|
|
```
|
|
|
|
**Chosen stack:**
|
|
|
|
**Frontend:**
|
|
- `Next.js 13` - SSR, routing, optimizations
|
|
- `React 18` - Components, hooks, context
|
|
- `TypeScript` - Type safety
|
|
- `Tailwind CSS` - Modern styling
|
|
|
|
**Backend:**
|
|
- `.NET 7` - REST APIs
|
|
- `Entity Framework Core` - ORM
|
|
- `SQL Server 2019` - Database
|
|
- `Polly` - Resilience patterns (retry, circuit breaker)
|
|
|
|
**Why Next.js instead of keeping WordPress?**
|
|
- Performance (SSR vs monolithic PHP)
|
|
- Optimized SEO (critical for pharma)
|
|
- Modern experience (SPA when needed)
|
|
- Scalability
|
|
- WordPress kept only as CMS (headless)
|
|
|
|
---
|
|
|
|
### Phase 3: Integrations (Project Core)
|
|
|
|
#### 1. Salesforce - Campaigns and Order Registration
|
|
|
|
**Implemented solution:**
|
|
|
|
Salesforce was configured to manage two main functionalities:
|
|
|
|
**a) Discount campaigns:**
|
|
- Marketing configures campaigns in Salesforce (medication X, discount Y%, period)
|
|
- Backend queries active campaigns via API
|
|
- Frontend (Next.js) displays available discount percentage based on: medication + active campaign
|
|
|
|
**b) Order registration:**
|
|
- User informs: physician CRM, state, patient CPF, medication
|
|
- System validates data (real CRM via official API, valid CPF)
|
|
- Percentage calculated automatically (Salesforce campaigns + CMS rules)
|
|
- Order registered in Salesforce with all data (LGPD compliance)
|
|
|
|
**Overcome technical challenges:**
|
|
- OAuth2 authentication with automatic refresh token
|
|
- Rate limiting (Salesforce has API/day limits)
|
|
- Retry logic for transient failures (Polly)
|
|
- CPF masking for logs (LGPD)
|
|
|
|
---
|
|
|
|
#### 2. Twilio - SMS Authentication (2FA)
|
|
|
|
**Implemented solution:**
|
|
|
|
Two-factor authentication system to ensure security:
|
|
|
|
**Login flow:**
|
|
1. User enters phone number
|
|
2. Backend generates 6-digit code (valid for 5 minutes)
|
|
3. SMS sent via Twilio ("Your code: 123456")
|
|
4. User enters code in frontend
|
|
5. Backend validates code + expiration timestamp
|
|
6. JWT token issued after successful validation
|
|
|
|
**Compliance and audit:**
|
|
- Phone numbers masked in logs (LGPD)
|
|
- Complete audit (who, when, which SMS)
|
|
- Delivery rate: 99.8%
|
|
|
|
---
|
|
|
|
#### 3. Official Physician API (Regional Medical Council)
|
|
|
|
**Implemented solution:**
|
|
|
|
Automatic physician validation via official medical council API:
|
|
|
|
**Performed validations:**
|
|
- CRM exists and is active in council
|
|
- Physician name matches informed CRM
|
|
- Specialty is allowed (lab business rule)
|
|
- State corresponds to registration state
|
|
|
|
**Optimizations:**
|
|
- 24-hour cache to reduce official API calls
|
|
- Fallback if API is down (notifies admin)
|
|
- Automatic retry for transient failures
|
|
|
|
**Why this matters:**
|
|
Ensures only real and active physicians can prescribe discounts, avoiding fraud.
|
|
|
|
---
|
|
|
|
#### 4. WordPress as Headless CMS
|
|
|
|
**Implemented solution:**
|
|
|
|
Marketing continues managing content in WordPress (familiar), but frontend is modern Next.js.
|
|
|
|
**Architecture:**
|
|
- WordPress: Manages texts, images, campaign rules
|
|
- WordPress REST API: Exposes content via JSON
|
|
- Next.js: Consumes API and renders with SSR (SEO optimized)
|
|
|
|
**Benefits:**
|
|
- Marketing doesn't need to learn new tool
|
|
- Modern frontend (performance, UX)
|
|
- Optimized SEO (Server-Side Rendering)
|
|
- Clear separation of responsibilities (content vs code)
|
|
|
|
---
|
|
|
|
### Phase 4: Resilience & Error Handling
|
|
|
|
With multiple external integrations, failures are inevitable. The solution was to implement **resilience patterns** using Polly library (.NET):
|
|
|
|
**Implemented patterns:**
|
|
|
|
**1. Retry**
|
|
- If Salesforce/Twilio/CRM API fail, system automatically retries 2-3x
|
|
- Wait grows exponentially (1s, 2s, 4s) to avoid overload
|
|
- Only transient errors (timeout, 503) are retried
|
|
|
|
**2. Circuit Breaker**
|
|
- If service fails 5x in a row, "opens circuit" for 30s
|
|
- During 30s, doesn't try anymore (avoids wasting resources)
|
|
- After 30s, tries again (may have recovered)
|
|
|
|
**3. Timeout**
|
|
- Each integration has maximum response time
|
|
- Avoids indefinitely stuck requests
|
|
|
|
**4. Fallback (Plan B)**
|
|
- Salesforce down: Order goes to queue, processes later
|
|
- Twilio down: Alert administrator via email
|
|
- CRM API down: Uses cache (24h old data)
|
|
- WordPress down: Displays pre-loaded static content
|
|
|
|
**Strategies per integration:**
|
|
|
|
| Integration | Retry | Circuit Breaker | Timeout | Plan B |
|
|
|----------|-------|-----------------|---------|----------|
|
|
| Salesforce | 3x (exponential) | 5 failures/30s | 10s | Retry queue |
|
|
| Twilio | 2x (linear) | 3 failures/60s | 5s | Admin alert |
|
|
| CRM API | 3x (exponential) | No | 15s | Cache |
|
|
| WordPress | No | No | 3s | Static content |
|
|
|
|
**Production result:**
|
|
- Salesforce had maintenance (1h) → System continued working (queue processed later)
|
|
- Twilio had instability → Automatic retry resolved 95% of cases
|
|
- Zero downtime perceived by users
|
|
|
|
---
|
|
|
|
## Overcoming Infrastructure Challenges
|
|
|
|
### Problem: Servers Not Provisioned
|
|
|
|
**Temporary solution:**
|
|
1. 100% local development (Docker Compose)
|
|
2. External service mocks (when credentials delayed)
|
|
3. CI/CD prepared but not active (awaiting infra)
|
|
|
|
**When servers arrived (week 6):**
|
|
- Deploy in 2 hours (already prepared)
|
|
- Zero surprises (everything tested locally)
|
|
- Smooth rollout
|
|
|
|
---
|
|
|
|
### Problem: Delayed Integration Credentials
|
|
|
|
**Impact:** Twilio and Salesforce took 3 weeks to be provisioned.
|
|
|
|
**Solution:** Create "mock" (simulated) versions of each integration:
|
|
- Twilio mock: Logs instead of sending real SMS
|
|
- Salesforce mock: Saves order to local JSON file
|
|
- CRM API mock: Returns fictional physician data
|
|
|
|
**How it works:**
|
|
- Development environment: Uses mocks (no credentials needed)
|
|
- Production environment: Uses real integrations (when credentials arrive)
|
|
- Automatic switch based on configuration
|
|
|
|
**Result:** Team stayed 100% productive for 3 weeks, testing complete flows without depending on credentials.
|
|
|
|
---
|
|
|
|
### Problem: Team Inexperienced with Modern Stack
|
|
|
|
**Context:** Team had no experience with React, TypeScript, modern .NET Core, REST APIs.
|
|
|
|
**Enablement approach:**
|
|
|
|
**1. Pair Programming (1h/day per developer)**
|
|
- Tech lead works alongside dev
|
|
- Screen sharing + real-time explanation
|
|
- Dev writes code, tech lead guides
|
|
|
|
**2. Educational Code Review**
|
|
- Not just "approve" or "reject"
|
|
- Comments explain the **why** of each suggestion
|
|
- Example: "Always handle request errors! If API crashes, user needs to know what happened."
|
|
|
|
**3. Living Documentation**
|
|
- ADRs (Architecture Decision Records): Why did we choose X and not Y?
|
|
- READMEs: How to run, test, deploy
|
|
- Onboarding guide: From zero to first feature
|
|
|
|
**4. Weekly Live Coding (2h)**
|
|
- Tech lead solves real problem live
|
|
- Team observes thinking process
|
|
- Q&A at end
|
|
|
|
**Result:**
|
|
- After 4 weeks, team was autonomous
|
|
- Code quality consistently increased
|
|
- Devs started doing code review among themselves (peer review)
|
|
|
|
---
|
|
|
|
## Results & Impact
|
|
|
|
### Successful Delivery Despite Challenges
|
|
|
|
**Context:** Program with multiple squads working in parallel.
|
|
|
|
**Achieved result:**
|
|
- **MVP delivered to production successfully**
|
|
- Controlled 2-month delay (significantly less than other program initiatives)
|
|
- All integrations working as planned
|
|
- Zero critical bugs in production (first week)
|
|
|
|
**Why was delivery successful?**
|
|
|
|
1. **Anticipated setup** - Git, processes, local Docker from day 1
|
|
2. **Strategic mocks** - Team wasn't blocked waiting for infra
|
|
3. **Solid architecture** - Resilience from the start
|
|
4. **Continuous upskilling** - Team learned by doing
|
|
5. **Proactive communication** - Risks reported early
|
|
|
|
---
|
|
|
|
### MVP Metrics
|
|
|
|
**Performance:**
|
|
- Loading time: <2s (95th percentile)
|
|
- Lighthouse score: 95+ (mobile)
|
|
- SSL A+ rating
|
|
|
|
**Integrations:**
|
|
- Salesforce: 100% orders synchronized
|
|
- Twilio: 99.8% delivery rate
|
|
- CRM API: 10k validations/day (average)
|
|
- SQL Server: 50k records/month
|
|
|
|
**Adoption:**
|
|
- 2,000+ registered physicians (first 3 months)
|
|
- 15,000+ processed discount orders
|
|
- 4.8/5 satisfaction (internal survey)
|
|
|
|
---
|
|
|
|
### Client Impact
|
|
|
|
**Digital transformation initiated:**
|
|
- Git implemented and adopted
|
|
- Established development processes
|
|
- Internal team enabled in modern stacks
|
|
- Cloud infrastructure configured (Azure)
|
|
- Evolution roadmap defined
|
|
|
|
**Foundation for future projects:**
|
|
- Architecture served as reference for other initiatives
|
|
- Documented code patterns (coding standards)
|
|
- Reused CI/CD pipelines
|
|
|
|
---
|
|
|
|
## Tech Stack
|
|
|
|
`.NET 7` `C#` `Entity Framework Core` `SQL Server` `React 18` `Next.js 13` `TypeScript` `Tailwind CSS` `Salesforce API` `Twilio` `WordPress REST API` `Docker` `Polly` `OAuth2` `JWT` `LGPD Compliance`
|
|
|
|
---
|
|
|
|
## Key Decisions & Trade-offs
|
|
|
|
### Why Next.js instead of pure React?
|
|
|
|
**Requirements:**
|
|
- Critical SEO (pharma needs to rank)
|
|
- Performance (physicians use mobile)
|
|
- Dynamic content (WordPress)
|
|
|
|
**Next.js offers:**
|
|
- SSR out-of-the-box
|
|
- API routes (BFF pattern)
|
|
- Automatic optimizations (image, fonts)
|
|
- Simplified deploy (Vercel, Azure)
|
|
|
|
---
|
|
|
|
### Why keep WordPress?
|
|
|
|
**Alternatives considered:**
|
|
1. Migrate content to database + custom CMS (time)
|
|
2. Strapi/Contentful (costs + learning curve)
|
|
3. **WordPress headless** (best trade-off)
|
|
|
|
**Advantages:**
|
|
- Marketing team already knows how to use
|
|
- Approved content was already there
|
|
- WordPress REST API is solid
|
|
- Zero cost (already running)
|
|
|
|
---
|
|
|
|
### Why .NET 7 instead of Node.js?
|
|
|
|
**Context:** Client had preference for Microsoft stack.
|
|
|
|
**Additional benefits:**
|
|
- Superior performance (vs Node in APIs)
|
|
- Native type safety (C#)
|
|
- Entity Framework (mature ORM)
|
|
- Easy Azure integration (future deploy)
|
|
- Client team had familiarity
|
|
|
|
---
|
|
|
|
## Lessons Learned
|
|
|
|
### 1. Infrastructure Delayed? Prepare Alternatives
|
|
|
|
Don't wait for servers/credentials to start:
|
|
- Local Docker is your friend
|
|
- Mocks allow progress
|
|
- CI/CD can be prepared before having where to deploy
|
|
|
|
**Lesson:** Control what you can control.
|
|
|
|
---
|
|
|
|
### 2. Processes > Tools
|
|
|
|
Even without corporate Git, I established:
|
|
- Branching strategy
|
|
- Code review
|
|
- Commit conventions
|
|
- Documentation standards
|
|
|
|
**Result:** When tools arrived, team already knew how to use them.
|
|
|
|
---
|
|
|
|
### 3. Upskilling is Investment, Not Cost
|
|
|
|
Pair programming and code reviews took time, but:
|
|
- Team became autonomous faster
|
|
- Code quality increased
|
|
- Natural knowledge sharing
|
|
- Simplified onboarding of new devs
|
|
|
|
---
|
|
|
|
### 4. Resilience from the Start
|
|
|
|
Implementing Polly (retry, circuit breaker) at the start saved in production:
|
|
- Twilio had instability (resolved automatically)
|
|
- Salesforce had maintenance (queue worked)
|
|
- CRM API had slowness (cache mitigated)
|
|
|
|
**Lesson:** Don't leave resilience for "later". Failures will happen.
|
|
|
|
---
|
|
|
|
### 5. Clear Risk Communication
|
|
|
|
I reported weekly:
|
|
- Blockers (infrastructure, credentials)
|
|
- Risks (deadlines, dependencies)
|
|
- Alternative solutions (mocks, workarounds)
|
|
|
|
**Result:** Stakeholders knew exact status and had no surprises.
|
|
|
|
---
|
|
|
|
## Challenges & How They Were Overcome
|
|
|
|
| Challenge | Impact | Solution | Result |
|
|
|---------|---------|---------|-----------|
|
|
| No Git | Total blocker | Local setup + GitLab Cloud | Team productive day 1 |
|
|
| No servers | No dev environment | Local Docker Compose | Complete local dev/test |
|
|
| Delayed credentials | Integration blocked | Mock services | Progress without blocker |
|
|
| Inexperienced team | Low quality code | Pair prog + Code review | Ramp-up in 4 weeks |
|
|
| Multiple integrations | High complexity | Polly + patterns | Zero prod downtime |
|
|
|
|
---
|
|
|
|
## Next Steps (Post-MVP)
|
|
|
|
**Roadmap suggested to client:**
|
|
|
|
1. **Phase 2: Feature expansion**
|
|
- Dashboard for physicians (order history)
|
|
- Push notifications (Firebase)
|
|
- E-commerce integration (direct purchase)
|
|
|
|
2. **Phase 3: Optimizations**
|
|
- Distributed cache (Redis)
|
|
- CDN for static assets
|
|
- Advanced analytics (Amplitude)
|
|
|
|
3. **Phase 4: Scale**
|
|
- Kubernetes (AKS)
|
|
- Microservices (break monolith)
|
|
- Event-driven architecture (Azure Service Bus)
|
|
|
|
---
|
|
|
|
**Result:** MVP delivered to production despite starting literally from zero, establishing solid foundations for client's digital transformation.
|
|
|
|
[Need to build an MVP in a challenging scenario? Get in touch](#contact)
|