How we work
How We Build APIs
A predictable process, with the architecture agreed in writing before development starts.
The process
7 stepsDiscovery
We start from the business objective rather than the technology, and establish what the API actually has to answer.
- Business objective
- Users and callers
- Input data
- Required output
- Expected API volume
- Latency requirements
- Security requirements
- Third-party dependencies
- Deployment environment
Architecture
A written design you can review before development starts, so scope and cost are agreed on paper first.
- Endpoints
- Schemas
- Databases
- Authentication
- Infrastructure
- API versioning
- Error handling
- Scaling strategy
- Monitoring
Prototype
A limited working API, so the integration can be tested against something real rather than a document.
- Inputs
- Outputs
- Integration flow
- Model behaviour
- Performance
Production Development
The full build, with tests, documentation and security treated as part of the work rather than a later phase.
- API
- Data pipelines
- Databases
- Business logic
- Models
- Security
- Tests
- Documentation
Deployment
Deployed to an environment that suits your requirements, including your own infrastructure where preferred.
- AWS
- Google Cloud
- Microsoft Azure
- Dedicated Linux servers
- Private cloud
- Customer infrastructure
Integration
We support your engineering team through their integration, because an API is not delivered until something is calling it successfully.
Monitoring and Support
Once live, the service is watched continuously and supported on an agreed basis.
- Uptime
- Errors
- Latency
- Usage
- Model health
- Infrastructure load
- External provider failures
Technical capabilities
Technology should support the business outcome rather than dominate it. We choose from a deliberately conventional stack, and prefer boring tools where they are sufficient.
Backend
API Standards
Data
Infrastructure
Data Engineering
Machine Learning / AI
API quality principles
21 considerationsAn API that is genuinely production-ready has to account for all of this, whether or not it appears in a proposal.
Engagement models
MLPivot is a custom-development company, so there is no fixed public price list. Projects are scoped based on data complexity, integrations, model requirements, request volume, infrastructure and support requirements.
Fixed-scope prototype
A limited working API that proves the design before a full commitment.
Fixed-price project
An agreed scope, an agreed price, delivered against a written architecture.
Milestone-based development
Larger builds split into reviewable stages with payment per milestone.
Dedicated development team
Ongoing capacity for companies with a continuing roadmap.
Monthly API maintenance
Support, monitoring and updates for an API already in production.
Infrastructure management
Operation of the servers, deployments and monitoring around the service.
Ongoing data and model development
Continuous improvement of the data and models behind an intelligence API.
Enterprise SLA
Defined response times and availability commitments where the API is business-critical.
Want this applied to your project?
The first step is a discovery conversation about the objective, the data and the callers.