DEV Community

Cover image for I Built an ERP in 25 Hours With AI — Vibe Coding Is Getting Serious
Sanu Khan
Sanu Khan

Posted on

I Built an ERP in 25 Hours With AI — Vibe Coding Is Getting Serious

TL;DR: In roughly 25 hours, I went from requirements and architecture to a working full-stack ERP with a modern Angular UI, Laravel APIs, MySQL, operational workflows, dashboards, accounting features, reporting, and an integrated AI assistant.

Not a landing page.

Not a CRUD demo.

An actual ERP.

And the interesting part isn't that AI replaced the developer.

It didn't.

The interesting part is how much more a developer can now accomplish when AI becomes part of the engineering workflow.

From requirements to a working system

I started with what would traditionally become weeks of architecture discussions, boilerplate, migrations, APIs, UI screens, validations, and integration work.

The stack itself was intentionally conventional:

Angular
    ↓
REST API
    ↓
Laravel
    ↓
MySQL
Enter fullscreen mode Exit fullscreen mode

The goal wasn't to experiment with an exotic AI-generated architecture.

It was to see how quickly a conventional, maintainable application could be built when AI handled much of the repetitive implementation work while I remained responsible for architecture, constraints, review, and direction.

Within about 25 hours, the project had grown into a surprisingly substantial application.

It included areas such as:

  • authentication and authorization
  • multi-branch application context
  • users and roles
  • customer management
  • property management
  • agreement workflows
  • payment schedules
  • inward and outward transactions
  • receipts
  • petty-cash/daybook workflows
  • operational dashboards
  • accounts dashboards
  • maintenance workflows
  • inventory
  • purchase workflows
  • reports
  • audit-aware operations
  • AI-assisted ERP interaction

This wasn't generated from one magical prompt.

It was an iterative engineering process.

Codex became an implementation multiplier

A large portion of the development loop became:

Requirement
   ↓
Architecture / constraints
   ↓
Codex task
   ↓
Implementation
   ↓
Review
   ↓
Test
   ↓
Refine
Enter fullscreen mode Exit fullscreen mode

That distinction matters.

AI is extremely fast at producing code.

But producing code and engineering a system are still different things.

I still had to decide how modules should interact, where transaction boundaries belonged, what needed server-side validation, how authorization should work, how financial operations should behave, what should be immutable, and where the generated implementation needed simplification.

The project's backend, for example, uses explicit transaction boundaries for operations where partial success would be unacceptable.

The development workflow also retained the normal engineering concerns: backend and frontend testing, authorization verification, isolation checks, migration review, API compatibility, and regression testing.

AI accelerated those decisions into working software.

It didn't eliminate the decisions.

Then I attacked the UI

The first functional UI looked exactly like many internal systems do.

It worked.

But it looked like an ERP.

Tables. Forms. Cards. Navigation. Data.

Functional, but traditional.

So I used AI-assisted design iterations with Antigravity to rethink the frontend instead of accepting the usual "enterprise software has to look boring" assumption.

The direction moved toward a modern SaaS-style workspace:

Traditional ERP
     ↓
Functional UI
     ↓
AI-assisted design iteration
     ↓
Modern operational workspace
Enter fullscreen mode Exit fullscreen mode

The resulting interface uses a calm neutral canvas, dark navigation, rounded surfaces, stronger typography, compact controls, high-density tables, modern KPI cards, restrained gradients, and carefully placed accent colors.

The important lesson here was that AI wasn't only accelerating code generation.

It was accelerating design iteration.

Instead of spending hours manually experimenting with spacing, hierarchy, card treatments, dashboard composition, form density, and responsive behavior, I could describe the problem, evaluate an iteration, and immediately push it further.

The loop became:

Screenshot
→ critique
→ design direction
→ implementation
→ screenshot
→ refine
Enter fullscreen mode Exit fullscreen mode

That dramatically shortened the distance between "functional" and "polished."

And then came Zaakiy AI

The part I'm most interested in is the AI layer.

I call the assistant Zaakiy AI.

Instead of treating AI as a chatbot floating beside the application, the idea was to make it understand the ERP through controlled application capabilities.

For example, an ERP assistant should eventually understand questions such as:

"Show me agreements expiring soon."

"Summarize outstanding payments."

"Explain what's happening on this dashboard."

"Summarize this agreement."

"Show me open maintenance issues."

"Which inventory items are running low?"

The architecture deliberately avoids giving the model unrestricted database access.

Instead, AI operates through narrow application capabilities such as dashboard metrics, property searches, agreement retrieval, outstanding-payment queries, and controlled draft actions.

And that's an important distinction for production AI.

User
 ↓
Zaakiy AI
 ↓
Authorized application tools
 ↓
Application services
 ↓
Database
Enter fullscreen mode Exit fullscreen mode

Not:

AI
 ↓
"Here's the database. Good luck."
Enter fullscreen mode Exit fullscreen mode

AI should remain an assistant layer rather than becoming the system of record.

High-impact operations can still require explicit confirmation, while the backend continues enforcing normal authorization and validation.

That feels much closer to where enterprise AI is heading.

25 hours changed my perspective

I've been writing software long enough to recognize how much work normally hides behind something like this.

Database migrations.

Models.

Relationships.

Validation.

Authorization.

Controllers.

Services.

API resources.

Frontend services.

Types.

Forms.

Tables.

Filters.

Pagination.

Dashboards.

Error states.

Responsive behavior.

Tests.

Then the endless integration work between all of them.

AI compresses a huge amount of that mechanical work.

A feature that might previously consume half a day can sometimes reach its first working version in minutes.

That doesn't mean every generated line is correct.

It means the cost of iteration has collapsed.

And that changes how you build.

Vibe coding doesn't mean "don't understand the code"

This is where I think the conversation around vibe coding sometimes goes wrong.

There are two very different versions of it.

The dangerous version is:

Prompt
→ accept everything
→ ship
Enter fullscreen mode Exit fullscreen mode

The useful version is:

Understand the problem
→ define constraints
→ let AI implement
→ inspect the result
→ test
→ correct
→ simplify
→ repeat
Enter fullscreen mode Exit fullscreen mode

The second version is incredibly powerful.

You can spend less time typing repetitive code and more time thinking about architecture, edge cases, UX, data integrity, security, and what the product should actually do.

The developer moves up a level of abstraction.

AI isn't replacing developers. It's changing developer throughput.

After this experiment, that's the biggest takeaway for me.

The question isn't:

"Can AI build software?"

Clearly, it can build significant portions of software already.

A more interesting question is:

"What happens when an experienced developer can iterate at 5x or 10x their previous speed?"

Because that's what this felt like.

Not replacing engineering.

Amplifying it.

A developer who understands architecture, databases, APIs, security, frontend engineering, UX, and the business problem can now orchestrate multiple AI systems across the development lifecycle.

One AI helps implement.

Another helps critique the interface.

Another helps reason through architecture.

Another helps generate tests.

The developer remains the person connecting all of those outputs into one coherent system.

The bottleneck is moving

For years, a major bottleneck in software development was simply producing the implementation.

Writing all the migrations.

Writing all the endpoints.

Writing all the forms.

Writing all the components.

Writing all the tests.

That bottleneck is shrinking rapidly.

The new bottlenecks are becoming:

Can you describe the system precisely?

Can you design good boundaries?

Can you recognize when generated code is wrong?

Can you protect data integrity and security?

Can you design a coherent user experience?

Can you decide what should—and shouldn't—be automated?

Those are engineering questions.

And arguably, they're the more interesting ones.

25 hours. One developer. A lot of AI.

What I built would traditionally have required considerably more implementation time.

AI didn't magically make software engineering easy.

It made iteration unbelievably fast.

And once you combine that speed with engineering judgment, modern coding agents, AI-assisted UI design, and application-native assistants like Zaakiy AI, the amount of software one developer can produce starts looking very different.

Vibe coding isn't the end of developers.

It might be the beginning of a period where developers can finally spend less time translating decisions into boilerplate—and more time making the decisions that actually matter.

And we're still very early.

Top comments (0)