The ERP Is Dead.
Long Live the Flask App.

The ERP model made sense until the mid-2010s. You had one database, one system of record, one vendor — and for a long time it was a genuine improvement over spreadsheets, paper, and disconnected tools. The monolith was a real leap forward.

But the industry overfit to that model. What started as "let's centralize our data" became "let's model every possible business process in a single platform with modules for everything." And the more modules, the more customization required, the more consultants needed, the more dependency created.

The ERP vendor didn't trap you on purpose. But the incentive structure did its work just as effectively.

Say you're building a SaaS for a dog grooming business. The whole thing lives in one Postgres table:

CREATE TABLE appointments (
  id            UUID PRIMARY KEY,
  customer_name TEXT,
  dog_name      TEXT,
  dog_breed     TEXT,
  service_type  TEXT,         -- 'bath', 'haircut', 'nails', 'full_groom'
  groomer_id    UUID REFERENCES groomers(id),
  price         NUMERIC(10,2),-- exact decimal, not a float
  scheduled_at  TIMESTAMP,
  status        TEXT,         -- 'booked', 'in_progress', 'completed', 'cancelled'
  notes         TEXT
);

The "old school" approach: build a domain model, create a view model, add a service layer, DTOs, mappers. Five files and three abstraction layers before anything hits the screen.

The post-ERP approach: point Flask at that table and render it directly.

@app.route('/appointments')
def appointments():
    with get_db() as cur:
        cur.execute("""
            SELECT * FROM appointments
            WHERE status != 'cancelled'
            ORDER BY scheduled_at
        """)
        appointments = cur.fetchall()
    return render_template('appointments.html', appointments=appointments)

Each column maps 1:1 to a UI element. No view model, no mapper, no DTO. For this use case, that's not a shortcut — it's the correct architecture. Adding layers would be pure ceremony.

Now what about the "complex" view — a daily schedule grouped by time slot, with groomer names, showing revenue per day?

SELECT
    a.scheduled_at::date   AS day,
    a.scheduled_at::time   AS time_slot,
    a.dog_name,
    a.service_type,
    a.price,
    g.name                 AS groomer,
    SUM(a.price) OVER (
        PARTITION BY a.scheduled_at::date
    )                      AS daily_revenue
FROM appointments a
JOIN groomers g ON a.groomer_id = g.id
WHERE a.scheduled_at::date = %s
  AND a.status != 'cancelled'
ORDER BY a.scheduled_at;

cur.execute(query, [date])
rows = cur.fetchall()
# The query result IS your view model.

No ORM. No domain model. No service layer. No repository pattern. Just SQL that returns exactly the shape the UI needs.

PostgreSQL is already an incredibly powerful data transformation engine. JOINs, GROUP BY, window functions, CTEs — these do what half of those intermediate layers were built to do, but faster and closer to the data.

Note the NUMERIC(10,2) for price. Exact decimal precision, out of the box. No floating point rounding errors, no JavaScript float gymnastics. Postgres handles money correctly.

The "one person, many small apps" model always made sense in theory. In practice, it ran up against a real constraint: one person can only write so much boilerplate before burning out.

AI coding tools eliminate that constraint. Not by replacing domain knowledge — you still need to understand your business processes, your data, your users. But by handling the repetitive scaffolding that made the approach feel unscalable.

A business owner or operations manager who knows their processes and has basic SQL literacy can now build and maintain a suite of internal workflow apps that would have previously required a team or an expensive ERP contract.

This is why Flask + psycopg2 shines in the AI era. Simple, explicit code is easier to generate and easier to verify.
See the full AI workflow comparison →