devpilotLet’s build ↗
ARCHITECTURE

Strong foundations.
Clear boundaries.
Connected by design.

A Rust engineering engine, a PostgreSQL project record, and structured interfaces for the tools and people working with them.

THE SYSTEM AT A GLANCE
CLI ↔ MCP ↔ DPXray
↕
Gateway / project operations
↕
Rust engine + PostgreSQL
EXPLORE THE LAYERS

Different responsibilities.
One project context.

Select a layer to see its role. This diagram explains the architecture at a high level; it is not a live system monitor.

01 / INTERFACES

Meet the work where you are.

The dp CLI, MCP interface, and native macOS companion offer different ways to interact with project work. A terminal command and a visual project view serve different needs.

dp CLIMCP clientsDPXray / SwiftUI
DESIGN PRINCIPLE

An interface presents or requests work. It should not invent a second source of truth.

THE FOUNDATIONS

Purpose behind
the pieces.

01 / RUST

The engineering engine.

Rust underpins the CLI and core engineering services. Agent orchestration, project operations, and workflow logic belong in the engine.

02 / POSTGRESQL

The durable project record.

Project data, documentation, decisions, and checkpoint records provide continuity beyond an individual conversation.

03 / STRUCTURED INTERFACES

Tools that can work together.

The gateway and MCP interface give clients a structured way to request supported operations and retrieve project context.

A RECORD YOU CAN REVISIT

Keep the facts.
Trace the work.

The practical value of a project record is being able to retrieve it. A write acknowledgment alone is not the same as checking the saved result.

01

Record the milestone

Capture the decision, result, or checkpoint with the task context.

02

Read the result back

Retrieve the stored body or state and compare it with what was written.

03

Keep evidence attached

Retain the relevant source, artifact hashes, checks, and remaining gates.

BOUNDARIES MATTER

Ask the important
questions early.

Deployment and provider choices affect where work runs and where data travels. Evaluate the actual configuration for your use case.

Does local execution mean no data leaves the machine?+

Not necessarily. A local workflow can still call an external model or service. Data boundaries depend on the configured providers, tools, and permissions. Review those connections before using sensitive material.

Is every provider or client interchangeable?+

No universal compatibility is implied. Confirm the supported operations, provider setup, and interface behavior for the workflow you intend to use.

How should a team evaluate adoption?+

Start with a bounded pilot, agreed access, a concrete acceptance test, and clear human review points. Validate the chosen workflow before increasing its scope.

Where can I read more?+

The existing DevPilot technical site provides a broader product and architecture overview. Ask about the specific setup and operational boundaries that matter to your team.

MAKE YOUR NEXT MOVE

Your next idea deserves a team.

Start with the problem. We’ll explore the right path together.

Talk about your project ↗Explore the workflow →