This is a work-in-progress piece. I'm currently building an internal ERP system at PhonePe using AI tools to move faster than a traditional design-handoff-build cycle would allow. Here's what I've figured out so far.
ERP systems are the least glamorous design problem in product. Nobody does case studies on them. No one's writing Medium posts titled "How I redesigned the procurement module and changed everything." The users don't have a choice about whether to use it — it's mandated. The business case is efficiency, not delight. And yet these systems sit at the centre of how large organisations actually run.
I've been working on one at PhonePe. An internal tool that touches vendor management, approval workflows, contract lifecycle, and financial reconciliation. It's not the kind of work that makes it into a portfolio. But it's been the most technically interesting design challenge I've had in a while — partly because of the problem itself, and partly because of how I've been approaching the build.
The old way of building internal tools
Traditionally, internal tool design has a well-worn path. You do discovery, you map the workflows, you draw wireframes, you do design reviews, you hand off to engineering, you wait, you do QA, you wait again. For a system with 30+ screens across multiple user roles, that's a 3–4 month cycle before you have something real enough to test with the people who will actually use it.
The problem with that cycle is that internal tool users are experts. They know their own workflows better than any designer can from research sessions. The only way to find out if something works is to put it in front of them and watch them try to use it. Mock-up testing for an ERP tool is close to useless — the complexity lives in the edge cases, the exception states, the workflows that don't fit the happy path.
I wanted to get to a testable system much faster.
Enter Figma Make, Claude, and ChatGPT
The approach I've been using: design the component and interaction logic in Figma, use Figma Make to generate working React code from the design, use Claude to refine and extend that code, and use ChatGPT to sanity-check architecture decisions and generate boilerplate I'd otherwise write by hand.
None of these tools does the job fully on its own. Figma Make gets you maybe 60–70% of the way to a real component — the structure is right, the props are logical, but the state management is usually too simplified and the edge cases aren't handled. Claude is good at extending that foundation — give it the component and describe the edge case, and it'll handle it accurately and quickly. ChatGPT is better for reasoning through architecture questions, especially when I'm choosing between approaches and want to think out loud.
The combination changes the ratio of design time to working-prototype time dramatically. What used to take 3 weeks of design followed by 6 weeks of engineering is taking closer to 2 weeks of design-and-build combined — with a working prototype I can sit a real user in front of by week 3.
What this changes about the design process
The most interesting shift is in how I'm using research. Because I can get to a testable prototype so quickly, I'm running research sessions with something functional rather than something static. I'm watching real users try to do real things — approve a vendor, flag a contract for review, reconcile a discrepancy. The feedback I'm getting is qualitatively different from what you get from showing someone a Figma prototype. They're not reacting to the design. They're reacting to the system.
That changes what I learn. I'm catching workflow problems, not just UI problems. I'm seeing where the data model doesn't match the user's mental model. I'm watching people build workarounds in real time.
What I haven't figured out yet
A few things are still unresolved. The handoff from my AI-assisted prototype to a production-grade engineering implementation is messier than I expected. The code that Figma Make and Claude generate is good enough for a prototype but needs significant rework for production — accessibility, performance, integration with the actual backend, test coverage. I'm still figuring out how to structure the handoff so that the prototype work isn't thrown away.
I'm also navigating the organisational question of what it means for a designer to be writing production-adjacent code. Where does design end and engineering begin? I don't have a clean answer to that yet.
I'll write a fuller version of this once the project is further along. Right now I'm still inside it — which is probably the best time to be paying attention.