Skip to content
Schedule a Call

Build what's next.

Software. Intelligence. Automation. Machines.

We engineer digital systems — from web and mobile platforms to AI automation, ERP, POS, robotics, and the infrastructure that makes them work.

Schedule a CallExplore Our Capabilities

Your first call is with the engineer who writes the code.

Built by Bolt Fusion and in production

Engineering stories

Built and shipped.

Two full technical write-ups, not a screenshot and a sentence — and the systems we built end to end for TTouch Clothing.

See all case studies
WarmChats landing page: 'Turn new real estate leads into booked appointments automatically', trusted by agents using Zillow, open houses, and Facebook leads

Case study: built by Bolt Fusion for WarmChats, Inc.

WarmChats — AI booking for real estate

Real estate, AI automation, microservices

Always-first AI follow-up for agents: Claude qualifies and routes every new lead—buyer or seller—while GPT-4.1 replies instantly on email and SMS and books showings 24/7target, with every message tracked.

The problem
Real estate leads go cold fast. An agent who replies first usually wins the appointment, but leads arrive at all hours across email, SMS, Zillow, open houses and Facebook, and a human cannot be first every time.
The system
An always-on follow-up system that is first to every inbound lead: Claude reads each new lead and routes it by intent, GPT-4.1 replies across email and SMS in the agent's voice, and confirmed showings write straight to the calendar.
The engineering
Event-driven microservices: Next.js front end, NestJS and Django services, PostgreSQL. Each inbound message is an event; qualification, reply generation and calendar writes are separate consumers, so a failure in one does not silently drop a lead.
The result
Live in production at warmchats.com, built by Bolt Fusion for WarmChats, Inc., which owns the product.
Read the case study for WarmChats — AI booking for real estate
Case study visual for AI-assisted restaurant search and discovery product

Case study: built by Bolt Fusion

Intelligent restaurant search

Multi-tenant microservice, tiered search, observable by design

Conversational discovery with explicit routing, predictable AI unit economics, and latency targets suitable for high-volume production traffic.

The problem
Most AI products die after launch — too slow, too expensive, too unstable. Conversational discovery is easy to demo and expensive to run: send every query to a frontier model and cost scales with traffic.
The system
This is the routing we built so one didn't. Every query is classified before any paid inference runs, so most traffic never reaches a model.
The engineering
A multi-tenant NestJS microservice on PostgreSQL with PostGIS and pgvector, Redis for the cache, and row-level security for tenancy. Routing is deterministic and happens before spend, which keeps the unit economics predictable as volume grows.
The result
Most traffic resolves on a sub-100ms pathshipped. The measurements below say which figures are shipped and which are targets.
Read the case study for Intelligent restaurant search

Client story

Delivered project: built by Bolt Fusion for TTouch Clothing

Four systems for TTouch Clothing

TTouch Clothing is a fashion brand from Bangladesh. We built four of its systems end to end — design, apps, backends and databases: a courier-risk web app for online sellers, a wholesale portal, the Sudarshini saree store, and employee verification with its HR back office. All four are live.

See the four systems

Feature work

Features we shipped into other companies’ apps

Features we built inside apps other companies own. The apps are theirs: each card names the company and only the features that were ours.

See Bazzile on our work page
  • Bazzile's swipe browsing, from its App Store screenshots: a listing card over the map, with dismiss and like buttons beneath it — a feature Bolt Fusion built
    Swipe-based browsing
  • Bazzile's map, from its App Store screenshots: listings pinned by price across Paris, with the matched listing's card below — the Google Maps location matching Bolt Fusion built
    Google Maps location matching

Delivered project: features built by Bolt Fusion for Bazzile Technology SA

Bazzile

Features in the React Native app: swipe-based browsing, Google Maps location matching and Firebase real-time sync

100K+ downloads on Google Play (opens in a new tab)

The whole app’s install count on its Google Play listing — its reach, not a measure of our features. Read 30 September 2026.

Schedule a CallSee all work (12 projects)

Intelligent restaurant search

Good engineering makes complexity feel simple.

Follow a request through the system and see how routing, retrieval, and caching work together.

Each lane below follows one sample request through the router. Every request is classified before anything is spent.

Three-lane search architecture

  • Keyword lane — simple intents, no model call.

    PostgreSQL ILIKE with PostGIS geo filters. Roughly 80% of traffictarget, under 80mstarget.

    $0 marginal costshipped

    A simple search

    Sample query, illustrative: “sushi”

    1. Request The query arrives with the visitor's location.
    2. Router Deterministic rules read a cuisine: a simple intent. No model is asked.
    3. Cache Redis is checked under the tenant, the query, the location, the filters and the lane. A miss.
    4. Keyword lane PostgreSQL matches the cuisine and PostGIS keeps the venues nearby.
    5. Response Ranked venues go back, and the result is cached for the next request.

  • AI lane — complex intent becomes structured retrieval.

    Claude Haiku parses intent to JSON, then OpenAI embeddings and pgvector cosine similarity in Postgres. Roughly 20% of traffictarget, under 1200mstarget.

    ~$0.001 per searchtarget

    A descriptive search

    Sample query, illustrative: “cozy Italian place for date night”

    1. Request The query arrives with the visitor's location.
    2. Router The rules find a mood and an occasion that keywords cannot match.
    3. Cache Nothing is stored under this key yet. A miss.
    4. Intent parsing Claude Haiku turns the words into structured intent, as JSON. It never sees the venues.
    5. Retrieval OpenAI embeddings and pgvector cosine similarity rank the venues inside Postgres.
    6. Response Ranked venues go back, and the result is cached.

  • Cache lane — repeat demand disappears at the edge.

    Redis, 30-second TTL, key is tenant plus query plus geo plus filters plus classification. Under 15mstarget.

    30–40% hit ratetarget

    The same search again

    Sample query, illustrative: “sushi”

    1. Request The same query, from the same place, while its result is still cached.
    2. Router The same rules give the same lane, and the lane is part of the key.
    3. Cache A hit: the key matches a stored result.
    4. Response The stored result goes back. No database query and no model call.

Schedule a CallRead the case study for Intelligent restaurant search

From systems we shipped.

Each figure says whether it was measured (shipped) or is a target. Ask on the call and we’ll walk you through the architecture.

How we work with clients

Named engineers, a pilot first, and IP you own.

Senior-only teams, named engineers up front, 4–8 hours of overlap with US and EU, and you own the IP.

15+ developers

Our engineers work across the UK, Malaysia and Bangladesh.

Named engineers
Assigned before you sign. Your first call is with the engineer who writes the code.
Overlap hours
4–8 hours of overlap with US and EU working days.
Intellectual property
Assigned to you on payment.
NDA
Signed before scoping.

Engagement models

ModelShapeTimeline
MVP buildScope, architecture, shippable v18–16 weeks
Embedded teamRoadmap delivery with your PMsOngoing
Stabilise and scalePerformance, reliability, maintainabilityAs needed

Most engagements start with the two-week pilot below. We’ll give you a full quote for the wider build at the end of it, once we’ve seen the real codebase.

Two-week sprints, a demo at the end of each, a named escalation contact, and a written weekly report. Ask for a sample report and we’ll send a real one.

Two weeks. Fixed price. Full IP. No obligation.

A scoped slice of your real product, not a demo. You keep everything whether you continue or not.

  1. Week 1architecture and a working vertical slice
  2. Week 2iterate, harden, and write the handover document
  3. DeliverableRunning code in your repository, on your infrastructure, with a handover doc.

Schedule a CallStart a 2-week pilot

What we engineer

Technology is more than software.

We design and engineer systems that connect software, intelligence, automation, data, and the physical world.

Evidence: Proven
Shipped, with a case study or project
Evidence: Core
Repeated work
Evidence: Capable
We can engineer it; no delivery yet
Evidence: Lab
Research or prototype only

The system map

Different technologies. One engineering discipline.

Select any part of the map to see what it connects to, the work behind it, and where to read more.

Every part is listed beside the map, with what it does.

Parts

  • SoftwareWeb platforms, mobile apps and their backends.
  • AIModels, agents and retrieval.
  • AutomationWorkflows that act on a decision.
  • DataOne model of the business on a central server: PostgreSQL, Redis and vectors.
  • Business systemsERP and POS: the operations of the business.
  • RoboticsConceptVision, control and telemetry — nothing delivered yet.
  • CloudDeployment, release pipelines and observability.

Every connection, and three worked flows, on the capabilities page

  1. Software engineering

    Web platforms, mobile apps and the backends behind them.

    Evidence: Proven

    Linked work

    Software engineering in depth
    Software engineering: a layered stackFour layers — interface, API, services and data. A request flows down from the interface to the data, and the response flows back up.InterfaceAPIServicesDatarequestresponse

  2. AI & automation

    Agents, retrieval and workflows that act on a model's output.

    Evidence: Proven

    Linked work

    AI & automation in depth
    AI & automation: a router in front of the modelA request reaches a router, which sends it down one of three lanes — keyword search, the model, or the cache — and the result becomes an action.RequestRouterKeywordModelCacheActionclassified before any paid inference

  3. ERP & enterprise systems

    One model of the business, with each department as a module.

    Evidence: ProvenHR, payroll and a wholesale back officeEvidence: CapableFull ERP

    Linked work

    ERP & enterprise systems in depth
    ERP: modules around one data coreHR, finance, inventory, procurement, operations, sales, reporting, workflows and multi-branch sit on a ring, each connected to one shared data core.HRFinanceInventoryProcurementOperationsSalesReportingWorkflowsMulti-branchShareddata core

  4. POS & commerce

    Point of sale that keeps selling when the network drops.

    Evidence: CorePoint of saleEvidence: ProvenOnline and wholesale commerce

    Linked work (online and wholesale commerce)

    POS & commerce in depth
    POS & commerce: the till at the centreThe till sits at the centre, connected to stock, kitchen, receipts and reports. An offline queue holds sales while the network is down and syncs them when it returns.StockKitchenReportsReceiptsTillsyncs on reconnectOffline queue

  5. Robotics & intelligent systems

    The software side of machines: vision, control and telemetry.

    Evidence: LabConcept — not a shipped system

    We engineer software for machines; we don't manufacture hardware. We haven't delivered robotics work yet, and nothing here is a shipped system — ask us and we'll tell you exactly what exists today.

    Robotics & intelligent systems in depth
    Robotics: from sensor to machineA sensor feeds a vision model, which informs a decision, which a controller turns into an action on the machine. A concept, not a shipped system.SensorVisionDecisionControllerMachinefeedback
    Concept — not a shipped system

  6. Cloud, data & infrastructure

    Databases, APIs, containers, CI/CD and observability.

    Evidence: Core

    Linked work

    Cloud, data & infrastructure in depth
    Cloud, data & infrastructure: the release pipelineA change moves from commit to build, test, deploy and observe; what observation finds feeds the next commit.CommitBuildTestDeployObservewhat it finds feeds the next commit

Schedule a Call

How we build

A sequence, not a slogan.

Six stages, in order. Each one ends with something you can hold us to.

  1. Discover

    We agree on users, success metrics, constraints and risks, so everyone knows what “done” means before anything is designed.

    The business, users, constraints and goals, written down and signed off.

  2. Architect

    We define system boundaries, data ownership, integration contracts, and performance budgets before implementation begins.

    The architecture, the system boundaries, and the latency and cost budgets.

  3. Engineer

    Working software every cycle, with demos and an open backlog, so problems surface when they are cheap to fix.

    Reliable software and infrastructure, with a demo every cycle.

  4. Integrate

    Auth, data and deployments are integrated early, not at the end, and every connection between systems is written down.

    Systems, services, data and automation connected and documented.

  5. Deploy

    We release with monitoring, runbooks and a sensible cutover.

    CI/CD, containerised deployments and a runbook.

  6. Scale

    We support stabilisation after go-live, then improve the system against the success measures agreed in Discover.

    Performance, reliability and capability improved against the success measures.

Industries

Industries with delivered work.

Each links to what we built there: a write-up, a project on our work page, or the capability it comes from.

All industries

Schedule a Call

Insights

Notes from the systems we build.

Technical articles written from real work, every figure labelled.

All insights

FAQ

Questions? Answers.

Who writes the code?

Named engineers are assigned before you sign. Your first call is with the engineer who writes the code.

How much do our working hours overlap?

4–8 hours of overlap with US and EU working days. Two-week sprints, a demo at the end of each, a named escalation contact, and a written weekly report.

Who owns the IP?

You own the IP: it is assigned to you on payment. An NDA is signed before scoping.

Can we start small?

Yes. Most engagements start with the two-week pilot: a scoped slice of your real product, not a demo. Two weeks. Fixed price. Full IP. No obligation.

What kinds of projects do you take on?

Software, AI and automation, ERP and point-of-sale systems, and the cloud infrastructure under them — new builds, integrations, and hardening existing systems for scale. We haven't delivered robotics work yet. If you have a clear user or business outcome, we can usually map a sensible technical path.

How do you estimate timeline and cost?

After a short discovery, we break work into milestones with acceptance criteria. You get ranges tied to scope—not a single opaque number—plus options to phase features if budget or deadlines are tight.

What does your delivery process look like?

Discovery and plan first, then iterative builds with demos and a transparent backlog, then launch with monitoring and handoff materials. You are never guessing what we are doing week to week.

Can you work with our existing codebase?

Yes. We routinely join live products: code review, refactors, test coverage, performance work, and incremental feature delivery. We start with a short technical assessment so risks are explicit up front.

How do we get started?

Use the contact page to schedule a call or email us with goals, timeline, and any constraints. We respond with fit, suggested next steps, and what we would need from your side to begin.

Have a complex problem?

Let's turn it into an engineered system.

Schedule a CallTell Us About Your Project