Remote Monitoring Web App Development

I am looking for a development partner to deliver a specific, well-defined feature (detailed in Sections 4–6), and ongoing relationship covering infrastructure maintenance and continued application development.
This document is both a technical brief and a request for proposal. After reading it, we need you to come back to us with two things: confirmation that you (or your team) have the skills and experience to deliver this work, and a price and timeline for doing so.

About This Engagement

The product is a property monitoring platform: sensors installed in a property (temperature, humidity) feed a data pipeline that assesses damp, mould, and thermal risk, and generates reports for landlords and tenants. The work described here adds a new UI-driven workflow for triggering those reports, and modernises how the underlying analysis pipeline runs.
This brief covers two pieces of scoped work, plus context on how we intend to structure a longer-term relationship if this initial work goes well.

How We Structure Work With Development Partners

We split responsibility across three tiers. This matters for how you scope and staff this work, and for what access you should expect to be given.
Tier 1 — Infrastructure Hygiene
Full, ongoing access. This is the kind of work we'd expect a partner to own on a continuing basis:
• Security patching, IAM review, AWS service upgrades
• Backup, migration, and archive processes
• Cost optimisation and monitoring
• Installation and tuning of a DuckDB database (~29 million records) — a near-term piece of work in its own right that will have a ticket defined soon
Tier 2 — API & Application Development
Full access to the frontend and backend codebases, delivered against a stable, versioned data contract (Section 7) rather than needing access to our core analysis pipeline's source code:
• React UI components and screens
• Go API endpoints and services
• Integration with DynamoDB and our SQL database via defined interfaces
• Triggering the analysis pipeline via an agreed event schema (SQS/EventBridge) — not by reading or modifying its source
Tier 3 — Core Analysis Pipeline (restricted)
Our Python data-processing pipeline is the core IP of the business. Access to it is deliberately restricted:
• Held in a private, separate repository, access limited to a small number of people
• Any work that touches this pipeline is done under an NDA and IP-assignment agreement, and code is delivered as a build artifact via CI/CD wherever possible, rather than through standing repository access
• One of the two pieces of work in this brief does require direct access to this code, under those terms — this is the exception, not the norm, for the ongoing relationship
We're flagging this structure upfront because it affects staffing and process, not because we expect friction over it.

Technical Environment

For context when scoping — happy to go deeper on any of this in a follow-up call:
• Frontend: React
• Backend: Go
• Data storage: SQL database (storing of raw sensor data) and DynamoDB (processed raw data: home/account/sensor objects)
• Infrastructure: AWS — Lambda, SQS/EventBridge, S3, plus standard IAM/networking
• Analysis pipeline: Python (pandas-based), currently ~20 sequential processing stages, historically run as a script and now being migrated to run as a Lambda function
• Source control: GitHub — some repositories are private and access-controlled per the tiers above
• Near-term addition/product development: a DuckDB database holding approximately 29 million records and 100 data points per record. It is a set of data that predicts outcomes and retrofit opportunities for homes across the uk. It will need a UI and perhaps be a new business with new website.