I Built This Because I Was Tired of Building Admin Panels

It's Feb 16, 2026, and I'm doing something that feels both exciting and terrifying: I'm opening Omnismith to the public. After several months of development, the landing page is live, payments are integrated, the app works. This is the moment.

But let me back up and tell you why this exists.

The Problem I Kept Running Into

If you've worked as a developer-for-hire or in an agency, you know this pattern by heart:

1. Client needs an admin panel
2. You build it (again)
3. "Can we add a field for X?"
4. You write a migration, update the model, modify the form
5. "Actually, can we track Y over time?"
6. You add TimescaleDB, write aggregation queries, build charts
7. "Who changed this value last week?"
8. You implement audit logging
9. Repeat for the next 15 clients

Every project had the same base requirements, just different data structures. CRM for one client, inventory management for another, server monitoring for a third. Same features (CRUD, history, charts, access control), different schemas.

At some point, I got tired of it.

The EAV Realization

I started thinking: what if the structure itself was data?

This led me to Entity-Attribute-Value (EAV) architecture. Instead of hardcoding schemas in migrations, you define them in the UI:

• Attributes are your building blocks (like table columns)
• Templates are your schemas (like table definitions)
• Entities are your actual data (like table rows)

You want to track servers? Create attributes for Hostname, IP Address, CPU Cores, Memory GB. Combine them into a "Server" template. Done. No migration files. No deployment. No downtime.

You want to add OS version? Create the attribute, add it to the template. It's available immediately.

This isn't a new idea—Airtable does this beautifully, Notion databases do this, hell, even WordPress custom fields do a version of this. But I needed something that also handled:

• Metric ingestion for time-series data (think Datadog, but for any entity)
• Full audit history (who changed what, when, and why)
• Proper RBAC (role-based + resource-level access control)
• API-first architecture (with OpenAPI spec, ready for integrations)

So I built it. Using my own modular PHP framework (yes, the one I wrote about before), PostgreSQL with TimescaleDB for time-series, and Angular 21 for the UI.

What Makes This Different From Airtable

If you just need flexible schemas and basic CRUD, Airtable is fantastic. It's polished, has a great ecosystem, and works well for business teams. But here's what it doesn't do:

Time-series metric ingestion. Airtable stores snapshots—each record is a moment in time. Omnismith stores timelines. You can push metrics via API every 30 seconds (CPU usage, temperature, API request counts, sensor readings) and query them like: "Show me average CPU usage for the last 7 days." This isn't a workaround with linked records and formulas—it's TimescaleDB under the hood, built for this exact use case.

Full audit history without manual versioning. Every field change is logged automatically with who/what/when. No need to create separate "Version History" tables or complex automation rules to track changes.

AI that executes, not suggests. Airtable's AI generates formulas and field descriptions. Omnismith's AI creates templates, adds attributes, inserts entities, and queries your data. It has direct function-calling access to your database through the OpenAPI spec. It's not a documentation helper—it's a schema builder.

Flat pricing for developers. $99/month gets you 50,000 entities with all features unlocked. Airtable Team costs $20/seat, so 5 users = $100/month for 50K records—but you're locked into per-seat billing even if you're just using the API. Need RBAC? That's Business tier at $45/seat. Need audit logs? Same. Omnismith: everything's included.

API-first design. Full OpenAPI spec generated from code. Every UI action has an API equivalent. Built for developers who need programmatic control over their data platform, not just business users clicking through forms.

If Airtable is for marketing teams managing campaigns, Omnismith is for developers building IoT platforms, SaaS backends, or internal tools that need both flexible schemas and time-series analytics.

The AI Assistant That Actually Works

Here's where it gets interesting. I added an AI Assistant—but not the kind that gives you generic advice or writes code snippets. This one executes.

It's powered by Google Gemini 2.5 and has direct access to your Omnismith data through function calling. Watch what happens when you talk to it:

You: "Create a Server template with hostname, IP, OS, and CPU cores"

The assistant doesn't just tell you how to do it. It:

1. Creates a StringAttribute for "Hostname"
2. Creates a StringAttribute for "IP Address"
3. Creates a ListAttribute for "OS" with options like "Ubuntu", "CentOS", "Windows"
4. Creates a NumberAttribute for "CPU Cores"
5. Creates a Template called "Server"
6. Associates all 4 attributes with the template

You see all of this happen in real-time—streaming responses with visible tool execution.

You: "Add a new server called web-prod-01 with IP 10.0.1.50, Ubuntu, 8 cores"

It creates the entity, fills in all the attributes. Done.

You: "Show me all servers with more than 4 CPU cores"

It queries your data and returns the results in a readable format.

This isn't a chatbot that suggests changes. It's an agent that makes them. The LLM proxy layer (a custom Fastify server I built) handles streaming, tool orchestration, and authentication. The tools themselves are auto-generated from the OpenAPI spec. Everything is schema-aware.

For developers building systems for non-technical clients, this is huge. Your client can literally describe what they need in plain language, and the assistant scaffolds it. No training documentation, no "click here, then here, then submit" tutorials. Just conversation.

What You Can Actually Do With It

Right now, Omnismith is being used for:

• Personal AI assistants (data from Telegram bots, reminder systems)
• IoT device monitoring (temperature, humidity, motion sensors pushing metrics via API)
• User consent tracking (GDPR compliance, versioned agreements)
• Server fleet management (infrastructure inventory + metric dashboards)
• Product catalogs (headless backend for custom storefronts)

The free tier gives you 150 entities and 7 days of history retention—enough to validate an idea or run a small personal project. The Scale tier ($99/month) gives you 50,000 entities, 180 days of retention, and all features unlocked: AI Assistant, full RBAC, audit logging, dashboards, automations—no per-seat charges, no premium tiers. (Compare: Airtable Team is $20/seat for similar record limits, but RBAC and audit logs require Business tier at $45/seat.)

Full OpenAPI spec, so you can integrate it with anything. I use it via API tokens from custom scripts. The UI is in 8 languages.

The Tech Stack (For the Curious)

Backend:

• PHP 8.4 (strict types, readonly properties, enums, attributes)
• Custom modular framework (explicit DI, hexagonal architecture, DDD)
• PostgreSQL + TimescaleDB
• Transactional outbox pattern for domain events
• OpenAPI spec auto-generated from PHP attributes
• PHPUnit: Tests: 996, Assertions: 5775

Frontend:

• Angular 21 (zoneless, standalone components)
• Angular Signals for state management
• Angular Material + TailwindCSS
• rxResource for data fetching
• AG Charts for visualizations

AI Layer:

• Custom LLM proxy (Fastify + TypeScript)
• Google Gemini 2.5
• Function calling with OpenAPI-derived tools
• SSE streaming with visible tool execution

I've written about the framework before on dev.to (see my modular architecture series), and yes, Omnismith is built entirely on it. That's validation #1 that the architecture actually works at scale.

Current Focus & Roadmap

I'm building this in public and prioritizing core stability over "feature bloat". While it is in beta, I'm focused on perfecting the desktop experience and core data visualization:

• Current Visuals: High-performance line charts, stats, gauges, and lists (Advanced chart types in development).
• Workflow: Currently focused on core data-handling; a visual automation builder (aka "Business Processes") to trigger automated data updates on specific events is the next major milestone.
• Mobile: Optimized for desktop power-users; responsive mobile tweaks are rolling out weekly, but it's already usable.

This isn't a "replace everything" tool yet - it's a lean, functional engine for users who need simplicity and effectiveness without the enterprise clutter. It's functional, tested, and solving real problems for the handful of users I've soft-launched with.

Why I'm Telling You This

I'm a developer. I know how to write code, architect systems, and ship products. What I don't know how to do is market things with loud, empty promises.

I'm not going to tell you Omnismith is "revolutionary" or "unprecedented" or will "transform your workflow." It's a tool. It solves a specific set of problems (flexible schemas + time-series + audit history) better than cobbling together Airtable + Datadog + custom code.

If you've ever built an admin panel and thought "there has to be a better way," this might be that way. If you need to track things (servers, products, sensors, contracts, whatever) and see how they change over time, this is built for that.

Try it. Break it. Tell me what's wrong. I'm listening.

👉 omnismith.io
👉 app.omnismith.io (150 entities free, no credit card)
👉 swagger.omnismith.io

---

P.S. The AI Assistant demo is real. Log in, hit the AI Assistant menu, and try: "Create a Product template with name, price, and SKU". Watch it work.

P.P.S. If you're curious about the modular framework powering all of this, I've written a series about it: Solving PHP's Module Coupling Problem.

Comments

[shemith mohanan]

This resonates a lot — rebuilding admin panels over and over is basically a hidden tax of agency work. Turning schema into data instead of migrations feels like a natural evolution. Curious how you’re handling performance as attribute counts scale?

[HomelessCoder]

Thanks for the question!

Regarding performance, EAV can definitely be slow if it's not handled correctly. I’ve built the backend engine to specifically avoid the "join hell" that usually happens when you add more attributes, so it stays efficient as you scale. I also use a strategy for data segmentation and partitioning to make sure the database only looks at the necessary parts of the data. For the time-series side, TimescaleDB is a huge help because it automatically breaks data into chunks, which keeps queries very fast even when you have millions of rows. It took some work to get the architecture right, but it’s designed to handle the load.