A unified platform of developer tools built as independent, production-grade products that share a common foundation — designed to work together as an ecosystem and stand alone as individual products.
- What Is This Ecosystem?
- The Problem This Ecosystem Solves
- Core Philosophy
- Ecosystem Architecture
- Products
- Foundation Layer — ecosystem-core
- Bridges
- Billing Engine
- Workspace Structure
- Terminology Glossary
- Product Status
- Roadmap
- Independent Growth Path
The Dev Ecosystem is a collection of developer-facing tools and infrastructure components built by a single author, designed with one guiding principle:
Each product must be able to survive, grow, and be monetized independently — but together they form something larger.
This is not a monolith and not a loose collection of scripts. It is a platform — structured like the foundation layer of a company, where every component follows shared standards for errors, logging, schemas, billing, and security.
The ecosystem currently includes tools for:
- Media processing (images, video, audio) — MediaProc
- Workflow automation and orchestration — Orbyt
- Secret and credential management — Vaulta
- Project scaffolding and dev environment tooling — DevForge
- Modern HTTP networking — Voxa
- AI-powered developer assistant (planned) — Dev Companion
Modern software development requires a developer to assemble and maintain a fragmented stack of tools that were never designed to work together:
- FFmpeg for video, ImageMagick for images, SoX for audio — each with completely different APIs and mental models
- GitHub Actions or cron for automation, but with no local execution story and no way to embed in your own tooling
- dotenv files, .env.local, AWS Secrets Manager, HashiCorp Vault — different tools for different environments, never composable
- create-react-app, Vite, custom scripts — project scaffolding that diverges per framework, per team, per year
- Axios, node-fetch, ky, got — HTTP clients that each solve one problem well and leave everything else to the developer
Every category has tools. But no category has a platform — a coherent set of tools that feel like they were designed by the same hand, follow the same conventions, and can work together when needed.
When a developer tries to build a real automated workflow — e.g. "resize these images, upload to S3, update the database, send a confirmation email" — they face:
- No shared error language — each tool fails differently, logs differently, and exits with different codes
- No orchestration — they write ad-hoc shell scripts or GitHub Actions YAML that breaks outside CI
- No secret management — credentials are hardcoded, in
.envfiles, or scattered across cloud consoles - No observability — no unified view of what ran, what failed, how long it took
- No billing — when automation scales, costs are invisible until the AWS bill arrives
This is the gap this ecosystem fills.
| Problem | Solution |
|---|---|
| Fragmented media processing tools | MediaProc — one CLI, one syntax, all media types |
| No local-first automation engine | Orbyt — YAML workflows, DAG execution, runs everywhere |
| Insecure credential management | Vaulta — encrypted local secrets, Git-backed, zero-knowledge |
| Repetitive project setup | DevForge — scaffold any project type in seconds |
| HTTP client that needs 5 libraries | Voxa — modular HTTP client, install only what you need |
| No unified developer interface | Dev Companion — AI assistant that orchestrates all of the above |
| Inconsistent errors and exit codes | ecosystem-core — shared error standard across all products |
| Invisible automation costs | Billing Engine — usage event tracking from day one |
Right now, a developer building a serious automation project has to:
- Learn FFmpeg flags for image processing
- Write cron + bash for scheduling
- Hardcode API keys or set up a cloud vault
- Bootstrap a new project for every workflow
- Handle HTTP edge cases manually
- Debug silent failures with no observability
With this ecosystem fully realized:
# One day this should work
dev-companion run "resize all product images in ./photos to WebP, upload to S3, and notify me via email"Dev Companion translates that into an Orbyt workflow, loads secrets from Vaulta, runs MediaProc for images, uses Voxa for HTTP, and gives you a structured execution report — all locally, all verifiable, all auditable.
That gap — between natural language and reliable execution — is what this ecosystem is working toward.
Every tool here can be installed and used completely independently. A developer using only MediaProc never needs to know Orbyt exists. A team deploying only Orbyt never needs Vaulta. Integration is opt-in, not forced.
Components do not share business logic or runtime dependencies. They share standards — a common error code schema, exit code conventions, logging format, billing event structure, and workflow schema. This is enforced through @dev-ecosystem/core.
No product contains billing logic. Products emit usage events. A separate billing engine consumes those events and calculates cost. This keeps execution logic pure and billing logic centralized.
Orbyt (the automation engine) does not import MediaProc. MediaProc does not import Orbyt. Integration is done entirely through the adapter pattern — MediaProc provides a MediaProcAdapter that Orbyt can load. This is the same pattern used by HashiCorp's plugin ecosystem.
Each product lives under its own npm organization:
| Product | npm Org |
|---|---|
| MediaProc | @mediaproc/* |
| Orbyt | @orbytautomation/* |
| Vaulta | Rust crate (vaulta) |
| DevForge | @dev-forge/* |
| Voxa | @voxa-http/* |
| Foundation | @dev-ecosystem/* |
This allows each product to be open-sourced, published, monetized, or spun off as a company independently.
┌─────────────────────────────────────────────────────────────────┐
│ Dev Companion (AI Orchestrator) │
│ (planned — the unified interface layer) │
└────────────────────────────┬────────────────────────────────────┘
│ orchestrates
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ MediaProc│ │ Orbyt │ │ Vaulta │
│ CLI + │ │ Workflow │ │ Secret │
│ Plugins │ │ Engine │ │ Store │
└────┬─────┘ └────┬─────┘ └──────────┘
│ │
│ adapter │ runs workflows that use
└──────────────────┘
│
┌───────▼────────┐
│ OrbytEngine │
│ (universal │
│ execution │
│ engine) │
└───────┬────────┘
│ emits usage events
▼
┌───────────────┐
│ Billing Engine│
│ (core layer) │
└───────────────┘
▲
│ shared standards
┌───────┴───────────────┐
│ @dev-ecosystem/core │
│ (error codes, │
│ schemas, logging, │
│ exit codes, types) │
└───────────────────────┘
Bridges are thin integration packages that connect products to shared platform services (billing, analytics, identity, observability) without creating hard dependencies. A product imports a bridge, and the bridge talks to the platform service.
Product → Bridge → Platform Service
Repository: github.com/0xshariq/mediaproc
npm: @mediaproc/cli
Status: ✅ Stable — v1.0.0
Problem it solves:
Video needs FFmpeg. Images need ImageMagick. Audio needs SoX. Each has a completely different CLI syntax, different error output, and a steep learning curve. A developer doing routine batch processing ends up writing brittle shell scripts that glue these tools together. There is no single modern CLI that handles all media types with consistent, developer-friendly commands.
MediaProc is that CLI. One tool. One install. One mental model — regardless of whether you are resizing images, compressing video, or normalizing audio.
Key Features:
- Plugin architecture — install only what you need (
mediaproc add image) - Consistent command syntax across image, video, and audio
- Preset system —
--preset webinstead of raw FFmpeg flags - Advanced
--explainflag (human, verbose, JSON output modes) - 47 image commands, 8 video commands, 6 audio commands (v1.0.0)
- Pipeline plugin powered by Orbyt engine for YAML-based media automation
Package Structure:
@mediaproc/cli — CLI entry point
@mediaproc/core — Shared utilities, error types, file helpers
@mediaproc/pipeline — Orbyt-powered declarative pipeline plugin
Quick Start:
npm install -g @mediaproc/cli
mediaproc add image
mediaproc image resize photo.jpg --width 1920 --height 1080
mediaproc image convert *.jpg --format webp --quality 85
mediaproc add video
mediaproc video compress movie.mp4 --quality high
mediaproc add audio
mediaproc audio convert song.wav --format mp3Repository: github.com/0xshariq/orbyt
npm: @orbytautomation/engine
Status: ✅ Engine stable v0.6.0 — CLI in active development
Problem it solves:
GitHub Actions only works in CI. Temporal requires a server cluster. Custom shell scripts are not portable, not replayable, and fail silently. Cron jobs are blind — no logs, no retries, no dependency ordering. There is no lightweight, local-first automation engine that a developer can embed in their own tool, run from a CLI, and extend with custom adapters.
Orbyt is that engine. It defines a workflow language (YAML), executes steps in dependency order (DAG), handles retries and timeouts, fires lifecycle events, and runs entirely locally — with no cloud dependency required.
Key Concepts:
- Workflow — A YAML file defining steps, dependencies, inputs, retry logic, and timeout rules
- Step — A single unit of work executed through an adapter (
uses: mediaproc.image.resize) - Adapter — A plugin that handles a specific action namespace (built-in or external)
- DAG Execution — Steps with dependencies run in topological order; independent steps run in parallel
- Event Bus — Lifecycle events emitted on every state transition (step started, completed, failed)
- Dry-run / Explain — Validate and visualize what will happen without executing
Built-in Adapters:
cli— Shell commandsshell— Shell scriptshttp— HTTP requestsfs— Filesystem operations
External Adapters:
mediaproc.*— Provided by@mediaproc/pipeline
Package Structure:
@orbytautomation/engine — Core engine (published on npm)
orbyt/cli — Command-line interface (in development)
orbyt/sdks — Language SDKs (planned)
orbyt/api — REST API layer (planned)
Workflow Example:
version: "1.0"
kind: workflow
metadata:
name: image-pipeline
workflow:
steps:
- id: resize
uses: mediaproc.image.resize
with:
input: ./photo.jpg
output: ./output/resized.jpg
width: 1280
height: 720
- id: convert
needs: [resize]
uses: mediaproc.image.convert
with:
input: ./output/resized.jpg
output: ./output/resized.webp
format: webpRepository: github.com/0xshariq/vaulta
Install: cargo install vaulta
Status: ✅ Stable — Rust CLI, local-first
Problem it solves:
API keys end up in .env files committed to git. Tokens get hardcoded in scripts. Teams share credentials over Slack. Cloud vaults (AWS Secrets Manager, HashiCorp Vault) require infrastructure just to store a single key. There is no simple, fast, local-first tool for a developer to store, retrieve, and manage secrets securely — without a cloud account, without a server, without complexity.
Vaulta is that tool. Built in Rust for performance and correctness. Zero network dependency. Encrypted locally with modern cryptographic primitives. Git-compatible for backup.
Security Stack:
- Argon2 for key derivation with vault-specific salts
- ChaCha20-Poly1305 for authenticated encryption
- Zero-knowledge — data never leaves the device
- Git integration for version-controlled backups
In the Ecosystem:
Vaulta is the secrets backend for Orbyt workflows. A workflow can reference secrets.api_key and Orbyt will resolve it through Vaulta at execution time — no plaintext credentials in workflow files.
secrets:
vault: vaulta
keys:
api_key: services/my-api-keyQuick Start:
cargo install vaulta
vaulta init my-vault
vaulta add github
vaulta list
vaulta copy githubRepository: github.com/0xshariq/devforge-cli
npm: @dev-forge/devforge
Status: ✅ Stable — v1.x, published on npm and Docker Hub
Problem it solves:
Every new project starts the same way: copy-paste a starter, delete what you don't need, reconfigure TypeScript, set up linting, configure deployment. Every team has a slightly different setup. Every framework has a different scaffolding CLI that breaks every year. Project setup wastes hours that should be spent building.
DevForge automates the full project bootstrap — from creation to deployment — across all major frameworks and cloud providers, with a single consistent CLI.
Key Features:
- Project generation from curated templates (React, Next.js, Express, Angular, Vue, Rust)
- Cloud deployment to Vercel, AWS, GitHub Pages
- Codebase analytics — complexity, structure, health diagnostics
- Dependency auditing across npm, yarn, pnpm
- Environment health diagnostics and auto-fix
- Smart caching for repeated operations
- Docker and Docker Compose support
Quick Start:
npm install -g @dev-forge/devforge
devforge create my-app
devforge analyze
devforge deploy --platform vercel
devforge deps updateRepository: github.com/0xshariq/voxa-http-client
npm: @voxa-http/voxa
Status: ✅ Stable — Core package published, modular architecture complete
Problem it solves:
Axios is 32KB and bundles features most apps never use. Fetch is raw and has no retry, caching, or circuit breaker. ky is lightweight but limited. Got is 180KB and Node-only. Every project solving real HTTP problems ends up importing 4–5 libraries — axios + retry + cache + circuit-breaker + token management — with no unified configuration model.
Voxa solves this with a modular architecture: install the core (21KB) and add only the features you need. Everything shares one configuration model, one interceptor chain, and one error classification system.
Core Package (@voxa-http/voxa):
- Automatic retry with exponential backoff
- Response caching (memory / file / custom adapter)
- Request deduplication — identical concurrent requests share one response
- Priority queue for request ordering
- Rate limiting built-in
- SSRF protection
- Schema validation on responses
- Structured error classification
Add-on Packages:
| Package | Purpose |
|---|---|
@voxa-http/voxa-streaming-images |
Image streaming with progress tracking |
@voxa-http/voxa-streaming-videos |
Video streaming with progress tracking |
@voxa-http/voxa-http2 |
HTTP/2 Server Push support |
@voxa-http/voxa-graphql |
GraphQL query support |
@voxa-http/voxa-batch |
Request batching |
@voxa-http/voxa-offline |
Offline queue management |
@voxa-http/voxa-circuit-breaker |
Circuit breaker pattern |
@voxa-http/voxa-token |
OAuth/JWT token management |
@voxa-http/voxa-metrics |
Performance metrics tracking |
Repository: github.com/0xshariq/dev-companion
Status: ⏳ Planned — Foundation laid, not yet implemented
Problem it solves:
A developer building a real automated workflow today has to: learn FFmpeg flags, write Orbyt YAML, configure Vaulta secrets, scaffold a project with DevForge, and stitch together HTTP calls with Voxa — all manually, switching between tools and documentation constantly. The individual tools are good. The integration is painful.
Dev Companion is the unified interface that removes that friction. It is not a chatbot. It is an execution orchestrator with an AI interface — it understands what you want to do, generates the right workflow, loads the right secrets, runs the right adapters, and reports what happened in a structured way.
How It Works:
When a user says "resize all my photos and upload to S3", Dev Companion:
- Generates an Orbyt workflow with the correct steps
- Resolves secrets from Vaulta for S3 credentials
- Executes via
OrbytEnginewithMediaProcAdapter+HTTPAdapter - Streams execution events back to the user in real time
- Bills under the Ecosystem tier — not per-product pricing
MCP Servers (Background Services):
Dev Companion communicates with Docker, GitHub, and email services via MCP (Model Context Protocol) servers:
services/docker-mcp-server/ — Docker operations
services/github-mcp-server/ — GitHub repository actions
services/email-mcp-server/ — Email notifications
Why It Matters for Billing:
Dev Companion activates the Ecosystem billing tier. All product usage through Dev Companion is billed under a single unified subscription rather than per-component. This rewards integrated usage and makes the full ecosystem affordable for teams.
Package: @dev-ecosystem/core
Repository: github.com/0xshariq/dev-ecosystem-core
ecosystem-core is the shared infrastructure package used by all products in the ecosystem. It is not a product — it has no user-facing features. It defines the standards every product must follow.
| Module | Purpose |
|---|---|
ExitCodes |
Standard CLI exit codes (0 = success, 1 = user error, 2 = config error, etc.) |
ErrorTypes |
Error severity, category, and recoverability classifications |
BaseError |
Base error class all ecosystem errors extend |
ErrorCodes |
Global numeric error code ranges per domain |
mediaproc.errors |
MediaProc-specific typed error classes |
orbyt.errors |
Orbyt-specific typed error classes |
vaulta.errors |
Vaulta-specific typed error classes |
devforge.errors |
DevForge-specific typed error classes |
workflow.schema.zod |
Zod runtime schema for Orbyt workflow validation |
workflow.interfaces |
TypeScript types for workflow definitions |
adapter.types |
TypeScript types for the adapter system |
LogFormat |
Shared log format specification |
All ecosystem products use a unified numeric error code range:
| Code Range | Domain |
|---|---|
0 |
Success |
1–19 |
User input errors |
20–39 |
Config / schema errors |
40–59 |
Execution errors |
60–79 |
Adapter / plugin errors |
80–99 |
Network / IO errors |
100–119 |
Security errors |
200+ |
Internal / unexpected errors |
This means a MediaProc error code and an Orbyt error code are always in different namespaces and never conflict.
Bridges live in the bridges/ directory. They are thin integration packages that give ecosystem products access to shared platform services without coupling them to the platform's implementation.
A product imports a bridge. The bridge handles service communication, authentication, retries, and fallback. The product never talks to the platform service directly.
| Bridge | Purpose |
|---|---|
bridges/billing |
Emit usage events → billing engine receives them |
bridges/analytics |
Emit analytics events → analytics backend |
bridges/identity |
Validate user identity / session context |
bridges/observability |
Metrics, traces, and structured logging export |
bridges/feature-flags |
Feature flag resolution per user / plan / region |
bridges/governance |
Policy enforcement and compliance checks |
bridges/vaulta |
Thin client for talking to a running Vaulta instance |
Product Code
│
▼
Bridge (contracts + adapters)
│
├── LocalAdapter (for local dev / offline)
├── RemoteAdapter (for cloud / production)
└── MockAdapter (for testing)
Switching from local to cloud billing requires changing one adapter, not modifying product code.
The billing engine is a separate layer — not part of any product. Products never calculate prices, check subscription limits, or handle payment. They emit usage events, and the billing engine consumes them.
| Layer | Responsibility |
|---|---|
| Website | User accounts, plans, payment gateway, subscriptions |
| Bridge | Translates user identity + subscription into billing context |
| Billing Engine | Applies pricing rules, calculates cost, handles overrides |
| Products | Emit UsageEvent records only |
Every engine run carries an ExecutionOrigin:
interface ExecutionOrigin {
source: "dev-companion" | "component" | "api" | "cli" | "marketplace";
product?: "orbyt" | "mediaproc" | "vaulta" | "devforge";
accountId: string;
sessionId?: string;
}The BillingRouter uses this to choose between the component billing model (per-product pricing) and the ecosystem billing model (Dev Companion flat subscription).
Free — Builder Starter
- Limited monthly workflow runs and executions
- Local mode only
- Core CLI features
- No credit card required
Pro — Serious Developer
- Higher execution limits
- Parallel execution
- Advanced adapters
- Usage-based overage billing
Ecosystem — Full Stack Automation
- Activated by Dev Companion usage
- Unified billing across all products
- All products under one subscription
- Team collaboration features
Each product also has its own independent tier structure for users who only use that product.
The billing engine supports a layered override system:
- Free plan override — set price to zero (for contributors, testers, beta users)
- Usage credits — deduct from credits before billing real usage
- Discount overrides — percentage or flat discounts
dev-ecosystem/
├── ecosystem-core/ # @dev-ecosystem/core — shared standards package
│
├── products/ # User-facing tools
│ ├── mediaproc/ # @mediaproc/* — CLI media processing
│ ├── orbyt/ # @orbytautomation/* — workflow engine + CLI
│ ├── devforge/ # @dev-forge/* — project scaffolding CLI
│ └── dev-companion/ # AI orchestration layer (planned)
│
├── libraries/
│ └── voxa-http-client/ # @voxa-http/* — modular HTTP client
│
├── bridges/ # Platform integration adapters
│ ├── billing/ # Usage event emission → billing engine
│ ├── analytics/ # Analytics event export
│ ├── identity/ # User identity context
│ ├── observability/ # Metrics, traces, logs
│ ├── feature-flags/ # Feature flag resolution
│ ├── governance/ # Policy enforcement
│ └── vaulta/ # Vaulta secret store client
│
├── services/ # Background services / MCP servers
│ ├── docker-mcp-server/ # Docker MCP server for Dev Companion
│ ├── email-mcp-server/ # Email MCP server
│ └── github-mcp-server/ # GitHub MCP server
│
├── web/
│ └── web-docs/ # Ecosystem documentation website
│
└── internal-docs/ # Architecture notes, design decisions, plans
| Term | Meaning |
|---|---|
| Product | A user-facing tool that solves a specific problem (MediaProc, Orbyt, Vaulta, DevForge) |
| Foundation / Core | @dev-ecosystem/core — shared types, errors, schemas used by all products |
| Bridge | A thin integration package connecting a product to a platform service (billing, analytics, identity) |
| Adapter | A plugin that handles a specific uses: action in an Orbyt workflow (e.g., MediaProcAdapter) |
| Workflow | A YAML/JSON file defining steps, dependencies, inputs, and execution logic in Orbyt's format |
| Step | A single unit of work in a workflow, executed through an adapter |
| DAG | Directed Acyclic Graph — the dependency structure that determines step execution order in Orbyt |
| Engine | The OrbytEngine runtime that parses, validates, and executes workflows |
| Plugin | A MediaProc extension installed via mediaproc add <name> (image, video, audio, pipeline) |
| Usage Event | An atomic record emitted by a product describing what computation was performed |
| Billing Router | Core component that chooses between ecosystem billing and component billing based on execution origin |
| Execution Origin | Metadata on every engine run identifying which product/source triggered execution |
| Ecosystem Tier | The billing tier activated when Dev Companion orchestrates multiple products together |
| Dry-run | Execute validation and planning without actually running steps — supported by Orbyt and MediaProc |
| Explain | Show what the engine will do, in what order, with what dependencies — without executing anything |
| MCP Server | Model Context Protocol server — background services that expose tool APIs to Dev Companion |
| Product | Status | Language | Published |
|---|---|---|---|
| MediaProc | ✅ Stable v1.0.0 | TypeScript | npm — @mediaproc/cli |
| Orbyt Engine | ✅ Stable v0.6.0 | TypeScript | npm — @orbytautomation/engine |
| Orbyt CLI | 🔄 In Development | TypeScript | Not yet |
| Vaulta | ✅ Stable | Rust | cargo — vaulta |
| DevForge | ✅ Stable v1.x | TypeScript | npm — @dev-forge/devforge |
| Voxa HTTP Client | ✅ Stable | TypeScript | npm — @voxa-http/voxa |
| Dev Companion | ⏳ Planned | TypeScript | Not yet |
| ecosystem-core | ✅ Active | TypeScript | npm — @dev-ecosystem/core |
| Billing Engine | ⏳ Designed, Not Built | TypeScript | Not yet |
| Bridges | 🔄 Scaffolded | TypeScript | Not yet |
Goal: Each product works correctly and independently before any integration work happens.
- ✅ MediaProc v1.0.0 — image, video, audio CLI stable
- ✅ Orbyt engine v0.6.0 — core execution engine published
- ✅ Vaulta — Rust CLI stable, encrypted local secrets
- ✅ DevForge v1.0.0 — project scaffolding and deployment CLI stable
- ✅ Voxa — modular HTTP client published
- ✅ Orbyt CLI — run, validate, explain commands
- ✅ ecosystem-core — error codes, schemas, base classes for all products
- 🔄 MediaProc pipeline plugin — Orbyt-powered YAML automation (in progress)
Goal: Products can talk to each other through well-defined contracts, not hard imports.
- Bridge contracts defined for billing, observability, identity, feature flags
- Local adapters for all bridges (offline-first, no cloud required)
- Orbyt CLI stable release with full test coverage
- MediaProc pipeline plugin stable release
- ecosystem-core logging standard fully implemented across all products
- Vaulta bridge — Orbyt workflow secrets resolution end-to-end working
Goal: Usage is tracked and costs are calculable before real money is involved.
- Billing engine core —
UsageEventschema,BillingRouter, pricing rule engine - Remote adapters for bridges (cloud billing, remote observability)
- Voxa CLI — command-line interface for HTTP testing and scripting
- Orbyt distributed execution mode — run workflows remotely
- MediaProc remote pipeline scheduling — runs triggered by cloud events
- Per-product pricing tiers defined and enforced at the bridge layer
Goal: A single interface that orchestrates the entire ecosystem.
- Dev Companion core — natural language → Orbyt workflow generation
- MCP server integration — Docker, GitHub, email as tool APIs
- Ecosystem billing tier — unified subscription activated by Dev Companion
- Real-time execution streaming — watch workflows run step by step
- Dev Companion CLI — local AI assistant with no cloud lock-in
Goal: The ecosystem becomes a platform others can build on.
- Orbyt adapter marketplace — community-contributed adapters for any tool
- MediaProc plugin marketplace — community plugins (PDF, SVG, 3D, etc.)
- Orbyt cloud engine — remote execution with persistent state
- Full observability dashboard — unified view across all products and workflows
- Multi-tenant billing — team accounts, usage aggregation, invoice generation
- Enterprise governance — role-based permissions, audit logs, compliance exports
Each product in this ecosystem is designed with eventual independence in mind:
| Product | Independent Path |
|---|---|
| MediaProc | Can grow into a company selling media automation APIs + CLI to agencies and SaaS products |
| Orbyt | Can be positioned as a developer-grade alternative to GitHub Actions + Temporal for local-first automation |
| Vaulta | Can grow into an enterprise secrets manager with team vaults, audit logs, and cloud sync |
| DevForge | Can become the standard project scaffolding platform across all languages and frameworks |
| Voxa | Can grow into an API platform — managed proxy, request analytics, rate limiting as a service |
| Dev Companion | Can become a standalone AI developer assistant that embeds the full ecosystem |
The shared foundation (@dev-ecosystem/core) provides structural consistency without lock-in. Any product can vendor the small set of types it needs and cut the dependency at any time.
This is the difference between a platform and a monolith.
Built by @0xshariq