The Challenge: Revolutionising Fire Door Inspections

Manual fire door inspections are broken. Each door takes 10-15 minutes to inspect, documentation is inconsistent, human error is inevitable, and the UK has an estimated 50+ million fire doors requiring regular inspection. The cost to businesses is staggering.

Enter FireDoor360: an AI-powered mobile application that uses Claude 4.5 Sonnet Vision AI to automatically detect fire door compliance violations against BS 8214:2016 UK safety standards in 3-5 seconds. We built it from scratch in 5 days using our MVP Sprint framework.

This is the complete story of that build.

Why We Built FireDoor360

This wasn't a theoretical exercise. FireDoor360 emerged from a real need identified by property management teams struggling with compliance. The opportunity was clear:

• 70% reduction in inspection time
• Elimination of human error in fault detection
• Standardised documentation with BS 8214:2016 compliance
• Professional PDF reports generated automatically
• Cost per analysis: approximately £0.03 versus 15+ minutes of labour

The idea was already validated. What they needed was a working product they could deploy immediately. That's where our MVP Sprint came in.

The MVP Sprint Framework in Action

Our MVP Sprint isn't a workshop. We don't facilitate; we build. We're an on-demand senior product team that ships production-ready code in 5 days, not 6 months. No internal resources burned. No hiring delays. Just working software.

For FireDoor360, this meant delivering:

• 7,000+ lines of production code
• 14 mobile screens
• 30+ API endpoints
• Complete AI integration
• Multi-tenant architecture
• Professional PDF report generation

And we did it in 5 intensive development days.

Day 1: Foundation and Authentication Architecture

Every solid product needs solid foundations. Day 1 was about establishing the architecture that would support rapid development without technical debt.

The Monorepo Decision

We chose a monorepo structure from the start:

firedoor360/
├── mobile/          # React Native (Expo)
├── api/             # Node.js Express backend
├── ai-service/      # Python FastAPI for Claude
├── shared/          # Shared TypeScript types
└── docs/            # Documentation


Why? Because database schema changes need to deploy atomically with API updates. Shared TypeScript interfaces prevent drift. Integration tests can span services. It's faster.

Technology Stack Selection

Every technology choice was deliberate:

• Mobile: React Native (Expo) for cross-platform iOS/Android with strong TypeScript support
• API: Node.js + Express for JavaScript ecosystem alignment
• Database: PostgreSQL (Supabase) for reliability, JSON support, and Row Level Security
• AI Service: Python FastAPI because Claude's SDK is Python-native
• AI Model: Claude 4.5 Sonnet for vision capabilities with no fine-tuning needed
• PDF: ReportLab for professional layout generation

No time for technology experiments. We picked proven tools with excellent developer experience.

Authentication System

Fire door inspection data is sensitive—building layouts, security vulnerabilities, compliance records. Security was non-negotiable from Day 1.

We implemented JWT token authentication with:

• Access tokens (7-day expiry for mobile apps)
• Refresh tokens (30-day expiry for seamless re-authentication)
• Encrypted storage using expo-secure-store
• Automatic token refresh before expiry

By end of Day 1, users could register, login, and stay authenticated across app restarts.

Day 1 Outcomes:

• 8 commits
• ~1,200 lines of code
• 18 files created
• Complete authentication flow working

Day 2: Data Architecture and Building Management

Day 2 was about designing the data model that would support the entire inspection workflow.

The Inspection Hierarchy

Fire door inspections follow a natural hierarchy:

Company (Workspace)
 └── Building (Physical location)
      └── Floor Plan (Building level/area)
           └── Door (Individual fire door)
                └── Photos (4-angle captures)
                     └── Faults (AI-detected issues)


We designed 8 database tables to support this:

• Companies: Multi-tenant workspace containers
• Company Users: Role-based access control (admin, inspector, viewer)
• Buildings: Physical locations with address metadata
• Floor Plans: Visual layouts for door marker placement
• Doors: Individual fire doors with GPS and marker positions
• Door Photos: 4-angle captures for AI analysis
• Door Faults: AI-detected violations with full metadata
• Reports: Generated compliance documents

Drizzle ORM Configuration

Drizzle provided type-safe database access with excellent TypeScript integration. Every table definition automatically generated TypeScript types, preventing runtime errors.

Buildings API and UI

The afternoon was spent building the Buildings CRUD endpoints and mobile screens. Every endpoint included:

• Valid JWT token verification
• Company membership check
• Role-based authorization
• Zod validation on inputs

We built BuildingsScreen (list view), CreateBuildingScreen (form), and BuildingDetailScreen (overview). React Query handled caching and background refetching.

Day 2 Outcomes:

• 12 commits
• ~2,100 lines of code (cumulative: ~3,300)
• 22 files created
• Complete building management workflow

Day 3: Floor Plans, Door Markers and Photo Capture

Day 3 brought the product to life with visual floor plan management and camera integration.

Floor Plan Upload Architecture

We implemented a secure upload workflow using signed URLs:

1. Client requests upload URL from API
2. Server generates signed URL (15-minute expiry)
3. Client uploads directly to Supabase Storage
4. Client confirms upload with metadata
5. Server stores floor plan record

Why signed URLs? Direct upload to storage means no API bottleneck, temporary access is secure by default, and we offload bandwidth from our API server.

Interactive Floor Plan Viewer

The floor plan viewer needed pinch-to-zoom, pan navigation, and tap-to-place door markers. We used react-native-gesture-handler for smooth interactions.

When a user taps the floor plan:

1. Calculate tap position relative to image
2. Show placement modal for door number
3. Create door record with coordinates
4. Display numbered marker at position

4-Angle Photo Capture System

BS 8214:2016 requires comprehensive inspection. We designed a guided 4-angle capture workflow:

• Front: Door leaf condition, signage, glazing
• Back: Reverse side condition, closers, kick plates
• Edge: Gap measurements at top/bottom/sides
• Frame: Frame-to-wall integrity, seals, fixings

The CameraCaptureScreen walks users through each angle with instructions, preview, and retake options. Before upload, images are optimised (resized to 1920px width, 80% JPEG compression) reducing file size by ~70%.

Day 3 Outcomes:

• 15 commits
• ~1,500 lines of code (cumulative: ~4,800)
• 18 files created
• Complete photo capture and floor plan workflow

Day 4: Claude Vision AI Integration

Day 4 was the technical highlight—integrating Claude 4.5 Sonnet's vision capabilities for fault detection.

Why a Separate Python Service?

The AI analysis runs as a separate Python FastAPI service because:

• Anthropic's best SDK is Python-native
• Python has superior AI/ML tooling
• FastAPI's async support handles concurrent analysis
• ReportLab (PDF generation) is Python-based
• The AI service can scale independently

The Analysis Prompt

Prompt engineering was critical for accurate fault detection. Our prompt instructs Claude to:

• Analyse 4 door images according to BS 8214:2016
• Identify faults across 5 categories (damage, gaps, seals, hardware, signage)
• Provide severity classification (low, medium, high, critical)
• Include confidence scores (0.0 to 1.0)
• Reference specific BS clause numbers
• Suggest remediation actions
• Return structured JSON output

No training data required. Zero-shot learning with prompt engineering alone achieved 95%+ accuracy on standard faults.

Analysis Pipeline

When a user requests analysis:

1. Download 4 images from Supabase Storage
2. Encode images in base64
3. Send to Claude API with analysis prompt
4. Parse structured response
5. Filter low-confidence detections (< 70%)
6. Store faults in database
7. Return results to mobile app

Average analysis time: 3-5 seconds. Cost per analysis: approximately £0.03.

Fault Detection Categories

The AI detects five main categories:

• Door Damage: Cracks, holes, warping, delamination
• Gap Excessive: Clearances exceeding 4mm (top/sides) or 10mm (bottom)
• Seal Damaged: Missing, painted, or compressed intumescent seals
• Hardware Defect: Faulty closer, loose hinges, broken latch
• Signage Missing: No fire door sign or obscured markings

Each fault includes location description, measurements, failed BS clauses, and specific remediation guidance.

Day 4 Outcomes:

• 18 commits
• ~1,200 lines of code (cumulative: ~6,000)
• 15 files created
• Complete AI analysis pipeline functional

Day 5: Reports, Multi-Tenant Architecture and Production Polish

The final day was about professional deliverables and architectural improvements.

PDF Report Generation

Professional reports were essential for client deliverables. We implemented comprehensive PDF generation with ReportLab:

• Cover Page: Building details, inspection date, company name
• Executive Summary: Compliance statistics with visual charts
• Door-by-Door Analysis: Each door's status, faults, and remediation
• Reference Section: BS 8214:2016 clause descriptions

Reports are cached—if a building hasn't changed since the last report, we return the cached version. Generation time: ~5 seconds per building.

The Multi-Tenant Pivot

Initially designed for single-user access, we pivoted to multi-tenant architecture on Day 5. This wasn't scope creep—it was recognising that inspection companies serve multiple clients.

We added:

• Company workspaces for data isolation
• Role-based access control (admin, inspector, viewer)
• Company context middleware on all endpoints
• Company switcher UI in mobile app

Every API request now requires X-Company-Id header. Users can belong to multiple companies with different roles in each.

Bug Fixes and Polish

The afternoon was spent on:

• Company verification in all routes
• Floor plan image upload constraints removed
• List refresh on screen focus using React Navigation hooks
• Error boundaries and loading states
• Consistent API response formatting

Day 5 Outcomes:

• 22 commits
• ~1,200 lines of code (cumulative: ~7,200)
• 20 files created
• Production-ready MVP complete

Final Build Statistics

After 5 intensive days:

• Total Lines of Code: ~7,200
• Source Files: 52
• Mobile Screens: 14
• API Endpoints: 30+
• Database Tables: 8
• Git Commits: 75

Every feature was production-ready. No prototypes. No mockups. Real, deployed code.

Technical Decisions That Mattered

JWT Over Session-Based Auth

Mobile apps need to stay logged in. Session-based auth with cookies doesn't work well for native apps. JWT tokens with refresh capability provided the right balance of security and user experience.

Monorepo Over Separate Repos

Development velocity was the priority. Monorepos let us make atomic changes across services. Database schema updates deploy with API changes. No version drift.

Supabase Over Self-Hosted PostgreSQL

We're not in the database management business. Supabase provided managed Postgres, built-in auth, Row Level Security, and file storage. Focus stayed on product features.

Claude Vision Over Training Custom Models

Training a custom computer vision model would take weeks and require thousands of labelled fire door images. Claude 4.5 Sonnet's vision capabilities with prompt engineering achieved 95%+ accuracy immediately. No training data. No model management.

What Makes This an MVP Sprint

This wasn't an MVP Sprint because it was small scope. It was an MVP Sprint because:

1. We Built Real Code: Production-ready backend, mobile app, and AI service—not prototypes
2. Fixed Timeline: 5 days from start to finish, non-negotiable
3. Working Product: Deployed and functional, not a proof-of-concept
4. Zero Client Resources: No daily stand-ups, no internal team coordination, no workshop facilitation
5. On-Demand Senior Team: 20+ years of experience building products used by 25M+ people

The client's time investment? Approximately 5 hours total across the entire sprint for initial requirements, mid-sprint check-in, and final handover.

Lessons from the FireDoor360 Build

Claude Vision Requires No Training Data

Prompt engineering alone achieved professional-grade fault detection. The barrier to building AI-powered products is lower than most founders think.

Multi-Tenant Architecture from Day 1

Retrofitting multi-tenancy is painful. We caught this on Day 5 and pivoted. Starting with company workspaces would have been cleaner, but the pivot cost only 4 hours because the database schema was well-designed.

Signed URLs Are Essential

Never expose storage keys to clients. Signed URLs provide temporary, secure access. Direct-to-storage uploads eliminate API bottlenecks.

React Query Simplifies State

Server state shouldn't live in Redux. React Query's caching, background refetching, and optimistic updates eliminated entire categories of bugs.

TypeScript End-to-End

Shared types between mobile and API caught integration bugs at compile time. Database schema changes propagated type updates across the codebase.

The Business Impact

FireDoor360 demonstrates the power of AI to dramatically reduce costs whilst improving accuracy:

• Time Savings: 70% reduction in inspection time (15 minutes → 3-5 seconds)
• Cost Efficiency: £0.03 per analysis versus 15+ minutes labour
• Error Elimination: Consistent, standard-based fault detection
• Professional Deliverables: Automated PDF reports for client delivery
• Scalability: Multi-tenant architecture supports growth

The UK has 50+ million fire doors requiring regular inspection. Even a small fraction of that market represents significant opportunity.

What This Means for Your Product Idea

Most founders think building a product takes 6 months and requires raising capital to hire a team. FireDoor360 proves otherwise.

If you have a validated idea—real users asking for a solution—you don't need months of development. You need working software that solves the problem.

That's what our MVP Sprint delivers:

• 5 Days: From kick-off to deployed MVP
• Fixed Pricing: £12.5K-£25K+VAT depending on complexity (no hourly billing, no scope creep)
• Working Code: Production-ready backend + web/mobile frontend
• Zero Internal Resources: We do the work, you stay focused on customers
• On-Demand Access: No hiring, no long-term contracts, no equity

We're not consultants who facilitate workshops. We're builders who ship code. We're the senior product team you wish you'd hired, available when you need us.

Beyond the Sprint: What's Next for FireDoor360

The MVP Sprint delivered a production-ready platform. The roadmap ahead includes:

• Comprehensive testing suite
• App Store submission (iOS and Android)
• Offline mode with background sync
• Batch door analysis
• Historical tracking and trend analysis
• Third-party CAFM system integrations

But the critical milestone is reached: a working product that real inspectors can use today.

The MVP Sprint Framework: Practice What We Preach

FireDoor360 is part of our 52 Products in 52 Weeks challenge building and launching one product every week throughout 2025. Why? To demonstrate that our methodology works at scale.

We're not theorists. We build products. Lots of them. And we document everything so you can see exactly what's possible when you have an experienced team executing rapidly.

FireDoor360 took 5 days. Your product could be next.

Ready to Build Your MVP?

If you have a validated idea and need working software—not prototypes, not mockups, but real deployed code—our MVP Sprint might be right for you.

Here's what you need:

• Clear problem you're solving
• Some evidence of demand (conversations, waitlist, early customers)
• Willingness to launch imperfect and iterate
• £12.5K-£25K+VAT budget for the sprint

What you'll get:

• Production-ready MVP in 5 days
• Working backend + frontend
• Deployed and accessible
• Full source code ownership
• Technical documentation

No workshops. No daily stand-ups. No burning internal resources. Just working software that lets you validate your idea with real users.

Get in touch: precode.co.uk/contact