Custom Software Development
Updated
≤11 days
Median time from spec freeze to first production deploy
Source: ColdAI internal benchmark, 2026
Zero-trust
Default network and identity architecture on every build
24/7
Managed-operation SLA available on every shipped platform
What does ColdAI do for Custom Software Development?
ColdAI's development practice builds the production systems that strategy papers and proofs of concept point towards: multi-agent applications, event pipelines and distributed-ledger integrations, along with the cloud infrastructure they run on. A small senior team works inside your repositories and accounts, ships something deployable at the end of every fortnight and writes down each significant design choice, so the system can be run by your own engineers or by us once it is live.
“We don't ship prototypes that the client then has to harden. The first commit on every project is the production deployment pipeline; everything else is built against it.”
What capabilities does ColdAI bring to Custom Software Development?
In depth
Engineering guides for the situations above
Each guide takes one situation from this page and works through it in detail, from release gates for agents to proving that a handover worked.
- 01ProcessAI agent production readiness: from PoC to liveThe gates an AI agent must clear before it touches live data: evaluation thresholds, tool permissions, red-team evidence, PII, tracing, failover and rollback.
- 02ArchitectureScaling a Kafka pipeline from one team to manyHow to turn a single-product Kafka pipeline into a shared event platform: topic ownership, schema compatibility, partition keys, team isolation and migration.
- 03Deep diveReconciling Hedera transactions with your ERP ledgerHow to reconcile Hedera activity with the general ledger: mirror-node data, a unique key per record, posting rules for fees and tokens, cut-off and audit trail.
- 04GuideArchitecture decision records: a practical guideHow to write and maintain architecture decision records: a template, what deserves one, superseding old records, and worked examples from AI and ledger systems.
- 05ChecklistSoftware handover checklist: vendor to in-house teamA checklist for taking over software an outside team built: code, infrastructure, documentation, runbooks, access, licences and the tests that prove each item.
When a build partner makes sense
Teams usually call us when a system has outgrown its prototype, or a deadline has outgrown the team. An agent proof of concept impressed the executive committee; now it must pass a security review, handle live customer data and survive a failover test. A Kafka pipeline built for one product line has to carry events for five. A Hedera integration must reconcile with the finance ledger before year-end audit. Or approved headcount will not arrive for two quarters. The buyer is typically a CTO, head of engineering or product owner who needs production code in TypeScript, Python, Rust or Go, handed over in a state their own engineers can run.
From requirements to running system
Five stages, each closed by a decision you make on evidence
Requirements and architecture
Business requirements, technical constraints and non-functional targets for latency, availability and recovery. Output: a system design document and the first architecture decision records. Decision: approve the architecture and the scope of the first release.
Sprint delivery
Two-week sprints with continuous integration and automated test suites; every sprint ends in working, deployable software and a demonstration. Output: sprint demo, release notes, updated backlog. Decision: reprioritise the backlog for the next sprint.
Verification
Automated unit, integration and end-to-end tests, performance benchmarking, security auditing and accessibility checks. Output: a test and security report with open findings ranked by severity. Decision: accept the residual risk or schedule fixes before release.
Production release
Blue-green deployment with automated rollback, monitoring and alerting in place before traffic moves. Output: the release in production, dashboards and runbooks. Decision: go or no-go, made against criteria agreed in advance.
Handover or continued operation
Output: handover sessions, documentation and transfer of all access. Decision: run the system with your own team, or keep ColdAI operating and extending it under a separate agreement.
What we hand over
| Deliverable | What it contains | Who uses it |
|---|---|---|
| Architecture decision records | Each significant choice, the options considered, the reasoning and the consequences, stored in the repository beside the code | Your architects and future maintainers |
| System design document | Context diagram, service boundaries, data flows, trust boundaries and the agreed non-functional targets | Platform, security and operations leads |
| Source code and infrastructure-as-code | Application repositories, Terraform modules, CI/CD definitions and dependency manifests, held in your version-control organisation | Your engineering team |
| Test and security reports | Coverage of unit, integration and end-to-end suites, performance benchmark results, vulnerability scan output and remediation status | QA, security and internal audit |
| Runbooks and dashboards | Deployment and rollback steps, alert definitions, incident procedures and monitoring dashboards | Operations and site-reliability engineers |
| Handover pack | Onboarding guide, known issues, deferred-work backlog, open-source licence list and a recorded system walkthrough | The incoming team or product owner |
What we build, and with what
The stack is chosen per system and recorded in an architecture decision record
Distributed systems
Event-driven microservices in Go, Rust or TypeScript, with message queues between services and distributed databases chosen for the consistency each workload needs.
AI and ML platforms
Model serving with vLLM, feature stores, training pipelines in PyTorch and Ray, and multi-agent orchestration exposed through real-time inference APIs with evaluation built into the pipeline.
Security-first engineering
Zero-trust identity between services, encryption at rest and in transit, and dependency and container scanning that blocks a merge when a critical finding appears.
Mobile and cross-platform apps
Native and cross-platform applications with offline-first storage that synchronises when connectivity returns, and biometric authentication tied to device keys.
Data engineering
Streaming pipelines on Kafka, PostgreSQL for transactions, ClickHouse for analytics, and time-series databases for IoT and telemetry workloads.
Cloud-native infrastructure
Kubernetes on AWS or GCP, every environment defined in Terraform, and CI/CD pipelines that run tests, scans and deployments on each merge.
Build it yourself, hire a large firm, or hire us
| Internal team | Large consultancy | ColdAI | |
|---|---|---|---|
| Long-term ownership | Best. The people who build the system stay to run it | Often hands over to a separate run team | We build for handover from the first sprint, but we are no substitute for a permanent team |
| Time to a working team | Slow if you must hire; immediate if the team already exists | Can mobilise large numbers quickly, with mixed seniority | A small senior team, available once scoping is agreed |
| Depth in agents, streaming and ledgers | Depends on who you have been able to hire | Available, sometimes through specialist units or subcontractors | Multi-agent systems, Kafka pipelines and ledger integration are core work for us |
| Very large, long programmes | Possible with sustained investment | Better placed to staff many engineers across parallel workstreams | Not our model. We suit focused systems with a clear owner |
| Domain and legacy knowledge | Strongest. Knows the core systems and why they are built as they are | Often strong in regulated sectors through industry groups | Learned from your people; plan time for it in the first sprints |
| Commercial model | Salaried cost; hardest to scale down | Time-and-materials or fixed price, with formal change control | Agreed in scoping; fixed fee for defined phases where possible |
When another option will serve you better
- A template or low-code tool would do the job
- You want to own a permanent in-house team
- You have not yet decided whether to build
- Lowest day rate is the deciding factor
What engineering leaders ask first
Tell us what has to run in production
Describe the system you need, the constraints it must meet and the date that matters. We will read what you already have and come back with an architecture approach, a first-release scope and an honest view on whether we are the right team.
Scope a buildInside one fortnight: how a sprint ends in deployable software
Each sprint is a loop with a fixed end point: a build that could go to production if you chose to release it. These are the steps inside that loop, not a separate approval process.
- Sprint planning
Your product owner orders the backlog and the team commits to the slice that fits, including any non-functional work the next release depends on.
- Build behind the pipeline
Every change goes through peer review and continuous integration; unfinished features sit behind flags instead of on long-lived branches.
- Automated verification
Test suites, dependency and container scans and, for AI features, the evaluation set run on each merge.
- Pipeline deploy to staging
The release candidate reaches an environment built from the same Terraform modules as production, deployed by the pipeline rather than by hand.
- Demonstration on the build
The team shows the deployed candidate and its release notes, so you judge the real artefact rather than slides.
- Backlog reprioritised
What the demonstration revealed changes the order of work for the following sprint.
What counts as deployable at the end of a sprint
Teams use the word 'done' loosely. These are the conditions a sprint's output has to meet before it is presented as finished. If one fails, the item returns to the backlog instead of appearing in the demonstration.
Non-functional targets to settle before architecture sign-off
The first delivery stage turns expectations into targets you choose. Each one changes the design, so it needs an owner and a way of being checked before the first sprint, not after the first incident.
| Target | The question to answer | How it is checked before release |
|---|---|---|
| Latency | How long may a person or calling system wait for each critical interaction, typically and at the slow tail? | Load tests replay realistic traffic against staging and report percentiles per endpoint |
| Availability | Which functions must stay up, and how much downtime per month or quarter is acceptable? | Failure injection on dependencies, then an error budget tracked from the first production release |
| Recovery | How much data may be lost, and how quickly must service return after a failure? | A timed restore from backup into a clean environment, recorded in the test report |
| Peak load and growth | What arrives on the busiest day, and what must the system absorb as volumes grow? | Spike and soak tests beyond the expected peak, with the breaking point written down |
| Residency and retention | Where may data be stored and processed, and how long must or may it be kept? | Review of regions and storage policies in the infrastructure code, plus tested deletion jobs |
| AI output quality | What pass rate on the evaluation set must an agent or model reach before it handles live work? | The evaluation suite runs in the pipeline, and a drop below threshold blocks the change |
| Unit cost | What may one request, inference call or ledger transaction cost at expected volume? | Cost telemetry in staging and during shadow traffic, compared with the budget before traffic ramps up |
Targets are recorded in the system design document. Where a target cannot be known yet, the document says so and names the sprint in which it will be measured.
Where the first sprint goes in five common starting points
Taking the situations described at the top of this page, these are the first moves. The opening sprint should remove the largest unknown, which is rarely the most visible feature; scoping confirms or changes the plan.
- If
Agent PoC going live
ThenBuild the evaluation harness, tracing and tool-permission model before adding any features.
Release depends on evidence a demo never produces; the agent production readiness gates describe it.
- If
Pipeline gaining product lines
ThenIntroduce a schema registry and topic conventions, registering existing event formats exactly as they are.
Contracts are the hardest thing to retrofit once more teams publish; see scaling Kafka across teams.
- If
Ledger reconciliation before audit
ThenIngest mirror-node data and produce a reconciliation report before automating any journal posting.
Seeing the mismatches first shows which posting rules you need; the reconciliation pattern covers the design.
- If
Hiring behind the roadmap
ThenCreate repositories, environments and pipelines in your organisation and pair your first hires with the team as soon as they join.
Handover costs least when it starts on day one; the handover checklist lists what must transfer.
- If
Inherited codebase
ThenUse the first sprint to read the code, infrastructure and incident history, and reconstruct the decisions that still shape the system.
Changing a system safely starts with knowing why it was built the way it was.
How custom builds drift off course, and the control for each
Troubled builds tend to show the same early signals. Each control below is part of how sprints run, not an extra phase bolted on at the end.
Non-functional targets surface at go-live
Early signalThe first load test or security review is booked for release week.
MitigationTargets agreed during requirements, measured from early sprints and reported in each demonstration.
Integration effort is underestimated
Early signalInterfaces to core systems are described from documentation nobody has exercised.
MitigationCall the real interfaces with sample data in the first sprint and record where they differ from their documentation.
Knowledge stays with the supplier
Early signalOnly the external engineers can deploy, debug or explain a design choice.
MitigationRepositories and accounts in your organisation, decision records beside the code and your engineers pairing on releases.
Agent quality is judged by demonstration
Early signalStakeholders approve an agent after watching a few hand-picked conversations.
MitigationAn evaluation set drawn from representative cases, with thresholds agreed before results are seen.
Scope grows without trade-offs
Early signalNew requests join the sprint while nothing leaves it.
MitigationOne ordered backlog owned by your product owner, and change handling written into the proposal.
Security review arrives after the code
Early signalThe threat model is drafted once the system is nearly finished.
MitigationTrust boundaries drawn in the system design document, with scanning active from the first merge.
Frequently asked questions
Can you take over a codebase that another team started?
Yes, and the first sprint is planned differently when we do. We read the code, infrastructure definitions, pipelines and recent incidents, rebuild an environment from scratch to see what breaks, and write decision records for the choices that still constrain the system. The result is a short assessment of what can stay, what needs repair before new features and what we would change first. If a rewrite would genuinely cost less, the assessment says so and explains why.
Can our own engineers join the sprint team?
Yes. Mixed teams are often the surest route to a clean handover. Your engineers take part in planning, reviews and on-call like everyone else, using the same accounts and permissions. Scoping settles who owns which part of the system, so responsibilities are clear in demonstrations and when something fails. The aim is that by the final sprints your people lead releases while our team supports them.
How do you test features built on language models when outputs vary?
The deterministic parts, such as tool wrappers, parsers and permission checks, get ordinary unit and integration tests. Model behaviour is tested against an evaluation set: cases drawn from representative data, each with a pass condition, scored automatically or by a written rubric. The set runs in the pipeline whenever behaviour could change, and falling below the agreed threshold blocks the change. Cost and latency are measured in the same runs. How we build and maintain those sets is covered in the LLM evaluation sets guide.
Do you only build on Hedera, or on other distributed ledgers too?
Hedera is where ColdAI's ledger work is deepest: the firm is a member of The Hashgraph Association and runs a dedicated Hedera practice. The wider distributed ledger work spans public and permissioned architectures. On any build, the choice of ledger, or of no ledger at all, is made during the architecture stage against your requirements and recorded together with the options that were rejected.
Can you commit to a fixed launch date?
A date can be fixed if scope is allowed to move. During scoping we agree the smallest first release worth launching, then order the backlog so the most valuable work lands first. Because every sprint ends in deployable software, a releasable version always exists, and the demonstrations show early whether date and scope still fit together. We will not promise both a date and a full scope without evidence that both are achievable.
What has to be in place on our side before sprint one?
A product owner with the authority to order the backlog and the time to attend reviews, a technical contact who can grant access, and accounts issued through your identity provider. Sample data or a sanitised extract helps, as does documentation for each system we must integrate with and the security policies the build has to meet. Missing pieces do not delay the start; gathering them becomes part of the first sprint.