The Work Before the Work

The most important decisions happen before you write a single line of code. Your choice of project, technology, and domain determines whether AI-augmented development succeeds or fails, way before you write your first prompt.

Understanding the Landscape First

Understanding your project, the domain you're tackling, the constraints and expectations - all of this comes before you write the first spec or the first prompt.

We set out to achieve a reasonable but complex project:

• Web and mobile-based UI
• Backend with a relational database at its core
• Backend/frontend technologies (.NET stack, Flutter) that we're familiar with and know how to debug
• Mostly CRUD-based operations - ERPs are typically CRUD-heavy, with interactions on the simpler end of the complexity spectrum
• Targeting a market that is right for us and that we can handle
• Understanding the support requirements and that we can actually handle them ourselves

Choosing the Right Fight

We didn't pick this project randomly. We picked it because it plays to a set of deliberate advantages:

Technology we know how to debug. When (not if) things go sideways, we can dig ourselves out of the ditch without waiting for an LLM to figure it out. The .NET ecosystem, PostgreSQL, EF Core - these are tools we've used for years. When the HttpClient cookie pooling bug leaked sessions across users, we could trace it through the middleware ourselves. When an EF Core query generated unexpected SQL, we could read the generated query and analyze. AI helped fix these issues faster, but we could have fixed them without it.

CRUD-heavy domain. ERPs are complex in breadth, not in algorithmic depth. 167 entities with relationships and status transitions is a lot of surface area, but each individual operation is a well-understood pattern: validate input, check permissions, update state, persist, notify. This is exactly where LLMs excel - lots of similar patterns, repeated across many entities, with conventions that can be codified.

Web + Mobile, relational DB at the core. Proven architecture. We're not inventing a new data model paradigm or building a distributed event-sourced system. We're building a newer, shinier wheel - one with all the bells and whistles that typical legacy projects in the space don't have (like live chat support built into each instance!).

A market that fits us. Small enough to reach, underserved enough to matter, not competing with SAP or Oracle. We know the users, we speak their language (literally - the system is bilingual EN/HR), and we understand their pain points.

Why This Matters

If you can't rescue yourself from a ditch without the LLM, you've already lost. The LLM will confidently walk you deeper into the ditch and tell you it's a feature.

We chose a project where:

• Our existing expertise covers the critical path
• The LLM covers the breadth we lack
• Getting stuck means "slow down," not "stop"

The Bottom Line

Understand the risks and advantages of your approach before you do any real work. Know the tooling and what it can and cannot reasonably support. Move fast and adjust, learn as much as you can - but learn on real projects with proper use, not esoteric POCs that barely resemble production.

A proof-of-concept that generates a CRUD app from a prompt teaches you very little about what happens when that app has 167 entities, 9 background services, multi-tenant isolation, and users who will find every edge case you didn't think of. Learn on the real thing.