Indigo One

All in one software for any busines.

Comment

Indigo One

One connected operating platform for local businesses, built by a business owner using OpenAI Codex as his primary engineering partner.

Inspiration

I'm not a professional software developer.

I'm a business owner from Peru, with direct experience running restaurants and other local businesses. For years, I searched for software that could manage those operations from one place.

I tried expensive platforms, free systems, and specialized applications. The affordable options were usually incomplete or poorly designed. The more capable products became difficult to justify once I included integrations, configuration, training, support, and additional staff.

The real cost was not only the subscription:

Real cost = Subscription + Integrations + Configuration + Training + Human dependency

I realized that many business platforms do not remove complexity.

They transfer it to the business owner.

A local business owner should not need to understand several applications, connect external services, duplicate information, or hire specialists simply to manage products, sales, inventory, employees, appointments, deliveries, and customer communication.

That frustration became the origin of Indigo One.

I decided to build the system I had spent years trying to find.

At first, I used tools such as ChatGPT, Claude, and Copilot to research technical concepts and evaluate whether the project was possible. I later tested different coding agents, but Codex changed the way I could work.

Codex became my primary engineering partner and was used for nearly the entire development of Indigo One.

I brought the operational knowledge, product decisions, requirements, and constant review. Codex helped me translate them into architecture, frontend interfaces, backend services, database migrations, integrations, tests, and deployment workflows.

What it does

Indigo One centralizes the daily operation of a local business in a single platform.

Area Capabilities
Core operations Products, sales, purchases, inventory, warehouses, and tax and fiscal documents
Commerce Point of sale, online storefront, delivery, reservations, and scheduled orders
Services and workforce Appointments, availability, employees, schedules, and an attendance kiosk with biometric verification
Logistics Couriers, order preparation, fulfillment, and delivery operations
Integrations Messaging channels, payment services, and external business platforms
Artificial intelligence Guidance, configuration, and operational execution through Avery

The modules are not intended to work as isolated applications.

A product registered in Indigo One can participate in inventory, point of sale, online commerce, delivery, and reporting without being recreated in every system.

The platform connects four user-facing surfaces—the administration application, the online storefront, the driver application, and the Indigo Alertas browser extension—through a shared backend that owns the business rules.

The point of sale uses local persistence and synchronization to continue operating through unreliable connections. Business data is isolated by company and branch, and access to capabilities is enforced through subscriptions, permissions, and policies.

Users can also create an isolated demo branch populated with sample business data. This allows them to explore operational flows without mixing test records with their real business information.

Products ───────┬── Inventory
                ├── Point of Sale
                ├── Online Store
                ├── Delivery
                └── Reporting

Customers ──────┬── Sales
                ├── Appointments
                ├── Messaging
                └── Delivery

Employees ──────┬── Schedules
                ├── Attendance
                ├── Permissions
                └── Biometric Attendance

Avery

Avery is Indigo One's agentic operating layer.

Centralizing many capabilities does not automatically make software easy to use. A platform can contain every required feature and still overwhelm the owner with settings, menus, and technical dependencies.

Avery reduces that complexity by understanding the current business and interface context. It can guide the user, answer operational questions, select structured tools, navigate the platform, and help execute approved actions.

The owner should be able to describe the desired result instead of learning how every module works internally.

Avery does not control business rules directly. The model interprets intent and selects capabilities, while Indigo One validates permissions, inputs, approvals, financial rules, inventory consistency, and data integrity.

Indigo Alertas

Indigo One also extends beyond its administration tab through Indigo Alertas, a Chrome extension for critical operational events.

It can surface native notifications and audio alerts while the owner or employee is working in another tab or application. The extension connects to the authenticated Indigo session and can return the user to the relevant operational area.

How we built it

I used OpenAI Codex across nearly the entire engineering process.

I did not start with finished technical specifications. I started with operational problems and progressively learned how to express them as architecture, contracts, data models, user interfaces, and tests.

Codex helped throughout the complete repository workflow:

  • Exploring the existing code before making changes.
  • Designing domain boundaries and contracts.
  • Implementing frontend and backend functionality.
  • Creating and reviewing database migrations.
  • Debugging runtime failures.
  • Writing tests and validation scripts.
  • Refactoring implementations that no longer fit the architecture.
  • Verifying complete flows across multiple applications.

Technology

  • Next.js, React, and TypeScript for the main administration interface.
  • Python and FastAPI for backend services.
  • PostgreSQL for persistent business data.
  • Separate domain contracts for different business capabilities.
  • A Chrome Manifest V3 extension for external operational alerts.
  • Direct model-provider SDK integrations.
  • Structured tools, policies, approvals, and execution auditing.

Avery's custom agent harness

Avery does not depend on LangChain, CrewAI, AutoGen, or another agent framework.

Its agent harness was built specifically for Indigo One on top of direct model-provider APIs.

The runtime implements:

  • The complete model-to-tool-to-model loop.
  • Dynamic tool discovery based on actor, surface, policy, and availability.
  • Structured schemas for model tool calls.
  • Durable sessions, turns, steps, and events.
  • Conversation history and memory compaction.
  • Approval checkpoints for sensitive actions.
  • Duplicate tool-call protection.
  • Streaming of responses and agent activity.
  • Skills with explicit contracts.
  • Subagent creation and coordination.
  • Execution limits, observability, and auditing.
User request
     │
     ▼
Context and permitted capabilities
     │
     ▼
Model selects an action
     │
     ▼
Indigo validates policy and input
     │
     ▼
The owning business domain executes
     │
     ▼
The result returns to the model
     │
     ▼
Avery responds or requests approval

This architecture keeps the language model separate from business authority.

The model can understand what the user wants. Indigo One determines whether the requested action is valid, permitted, and safe.

Challenges we ran into

Learning while building

The greatest personal challenge was learning software engineering while building a large system.

I had to progressively understand frontend and backend development, databases, migrations, APIs, authentication, infrastructure, testing, security, and AI agents.

Codex accelerated that process, but it did not eliminate the need for judgment.

Generated code could look correct while being incompatible, duplicated, insecure, or architecturally weak. I had to learn how to investigate the repository, challenge assumptions, reproduce failures, review changes, and reject solutions that did not fit the system.

Maintaining one connected architecture

Indigo One contains domains that directly affect each other.

Sales affect inventory. Purchases affect warehouses. Products appear in several sales channels. Employees have schedules, permissions, attendance, and operational responsibilities.

The challenge was connecting these areas without duplicating business logic or turning the platform into an unmaintainable monolith.

Building Avery's harness

Building a useful assistant is relatively simple. Building an agent that can safely operate a multi-tenant business system is not.

Without an agent framework, I had to build the lifecycle directly: model iterations, tool inventories, schemas, sessions, memory, approvals, streaming, execution records, loop limits, subagents, and recovery from incomplete tool exchanges.

The difficult part was not allowing Avery to call a function. It was ensuring that every action respected the correct business, branch, user, permissions, domain rules, and approval requirements.

External platform restrictions

Integrations such as WhatsApp, Messenger, Instagram, payments, and other external services have independent approval processes, costs, production restrictions, and regional limitations.

Some integrations are implemented but cannot yet be considered fully operational in production until those providers complete their reviews and approvals.

Accomplishments that we're proud of

Indigo One is no longer only an idea or a static prototype.

It now contains implemented domains and interfaces for:

  • Products, sales, purchases, inventory, warehouses, and fiscal documents.
  • Point of sale with offline synchronization and online commerce.
  • Delivery, couriers, and scheduled orders.
  • Employees, schedules, and an attendance kiosk with biometric verification.
  • Appointments and availability.
  • Integrations and messaging.
  • AI-assisted operations through Avery.
  • Isolated demo branches that let users explore the system without contaminating real business data.

I am particularly proud that I built this system without starting as a professional programmer and used Codex for nearly the complete engineering process.

Avery is also more than a chatbot added to the interface. It runs on a custom harness integrated with Indigo One's contracts, permissions, business domains, approvals, and audit trail.

Indigo Alertas extends the platform beyond the main web application, allowing important operational events to reach users outside the administration tab.

Indigo One is an actively developed working project, not a finished commercial release. Its platform, main business domains, connected applications, agent runtime, and operating model already exist. Some external integrations still require provider approval, while other areas continue to be tested and hardened.

What we learned

The most important lesson was that understanding the business problem is as important as understanding the technology.

A feature is useful only when it reduces work, eliminates a dependency, prevents an error, lowers a cost, or makes the business easier to operate.

I also learned that Codex is an engineering multiplier, not a replacement for responsibility.

It can explore, implement, debug, and refactor at a speed that would otherwise be impossible for me. But I still need to define the problem, review the result, detect incorrect assumptions, and decide what belongs in the system.

Another lesson was that autonomous software requires stronger controls, not weaker ones:

More autonomy requires stronger validation, clearer permissions, and better auditability.

Finally, I learned that my background as a business owner was not a disadvantage.

It gave me a direct understanding of the person who must pay for, configure, operate, and depend on the software.

What's next for Indigo One

The next stage is preparing Indigo One for real production use.

The immediate priorities are:

  • Complete pending external approvals.
  • Harden integrations and deployment.
  • Expand automated and end-to-end testing.
  • Validate the platform with real local businesses.
  • Simplify onboarding and initial configuration.
  • Extend Avery to more operational capabilities.
  • Improve execution tracing, recovery, and approval controls.
  • Continue adapting the platform to different local business sectors.

The long-term objective remains simple:

Instead of forcing business owners to adapt to disconnected software, Indigo One should adapt to the way their businesses actually operate.

Built With

Share this project:

Updates