The progress made on AI coding tools has been absolutely wild. I’m not a developer – I can get around a bit in HTML and CSS but definitely couldn’t reasonably market my skills as a front end engineer. However, like many product and design folks, I’ve had many ideas I wanted to try over the years – but without these development skills, I’ve had no ability to make them happen. So after seeing the promise of these AI coding tools, I thought I’d test them out to see how far they could take me.
The idea: back when I was consulting I was always annoyed that W9s were a pain to send and track, and I wanted a tool to quickly generate and send them. Not a huge pain point admittedly, more like one of those annoyances I always wanted to fix. I had briefly stood up a tool like this with an engineer friend, but he ultimately lost interest and we ended up shutting it down. So I wanted to find out – with the assistance of AI, could I recreate this tool on my own?
In short, yes, and relatively quickly. Introducing W9er.
How I did it:
- Figma for designs
- v0 for front end code
- Cursor for full code functionality
- Stripe for payment processing
- Heroku for deployment
First, I created a quick mockup in Figma. I didn’t spend a lot of time here getting to high fidelity, just enough to shape the app. I could have probably gotten away without this, as the final version deviated quite a bit from the original designs. If you are not a designer, you can get away with very rough wireframes here that outline the basic content and interactions.
Next, I exported those screens from Figma and dropped them into v0. Along with the screens, I added a description of the service, what it was for, what it needed to do, etc, into the v0 prompt field. Basically a very lazy PRD.
I clicked submit and v0 began writing the code! It created a working front end of the tool in seconds. You could even click through the experience in the preview mode. However, since v0 only does front end, nothing actually works – so now I needed it to actually function. To do that, I needed a more complete codebase, and to get that, I needed Cursor.
I exported the code from v0 to Cursor. This was a little touch and go. I thought this would have been a bit easier but there were some hurdles that took some trial and error to overcome, but the Cursor AI was able to help me. Once the code was in Cursor, I opened up a “Composer panel,” and used the same prompt I did in v0 to teach the tool what I was trying to build. I explained this was only the front end code and we needed to add real functionality to make it work. It took a first pass at it and got some things right and others wrong.
From here it was a lot of trial and error, but relatively quick progress. I would click through the experience until I hit a roadblock, and then explain the roadblock to the Cursor Composer, which would then try to solve it. I just kept doing this until it worked. Any time I got an error, I would tell the composer what was happening, often including any error messages I got, and it would help diagnose. It took a lot of back and forth to get to a working app, but overall it was less than a few hours to get it up and running!
As I did a lion’s share of the work in Cursor, I learned a lot along the way to make the experience more productive:
- Be specific and clear with your prompt, and err on the side of more detail:
- Tell it specifically what you want it to do
- Be specific if there is anything you don’t want it to do
- It will occasionally go rogue and re-write parts of you app that you don’t mean for it to do as it is working on something totally separate, which can lead to other issues. I added guardrails to the end of my prompts to prevent that, along the lines of “please only write code directly related to this request. Do not alter any other content or functionality,” which helped stop that from happening.
- Use the “Composer” function, not chat. I am not entirely clear why they have both, and in my experience the Composer is far more powerful. Make sure “Agent” mode is turned on within Composer.
- You’ll have to use the Terminal from time to time to get your application running. The agent functionality in Cursor can handle some of this for you via the built in Cursor Terminal, but I often found it helpful for certain functions to have my own system terminal window running for the commands. You will get errors this way, and if you do, you can just copy and paste terminal messages into the composer, which helps Cursor understand and diagnose the error.
- You can do the same with console messages from the browser inspect tools. Copying the body of these and pasting them into Cursor with any needed context solved a lot of issues quickly. This would often be coupled with a screenshot.
- The Cursor Composer can read screenshots. If I got any UI error or other bugs, I would take a screenshot and share it with the composer for context, and tell it “please see attached screenshot” when explaining the error I received. It can parse them very effectively.
- If you are going to ask it to do something big to your application (like adding user registration or payments), first ask Cursor how to do it without code, and instead have it explain the steps to you. After explaining what I wanted to do, I would write: “do not write any code, please just show me the steps” – not only does this help you understand what is needed and removes the AI black box feeling, but it actually helps the system reason through and not go off the deep end – then you can do things step by step which is much easier to manage and undo.
- Checkpoints are a lifesaver – you can roll code back to a moment in time if something is FUBAR. Occasionally, I would go down a rabbit hole trying to do something and the take the entire app down with it. But checkpoints help you roll it back to a happier place.
- The Composer can help you with deployments – just ask it how! It will provide some recommendations and steps to push it live. If you have a preferred service (I like Heroku), you can ask how to push it to that service and it can help with that.
- I had some challenges porting v0 output to Cursor – it ended up creating multiple levels of the app directories which it then repeatedly got tripped up on. It took a little while to resolve, which it did only when I took a screenshot of the directory and shared the screenshot – only then did it understand some of the directory issues and resolve them.
My advice overall is that the process is going to be messy and you’ll make mistakes, but that shouldn’t stop you! The forward progress you will make will become addictive and you’ll get past those initial hurdles.
And now, the tool is live at w9er.cc! I can’t speak to the code quality, I would imagine real engineers would probably have a lot of thoughts on it. However, it works and is live, so from a product perspective this is good enough to get a working prototype into production and test it out, which is what I wanted to do with W9er. Do I think this is going to be a high earning, barn-burner app? Probably not. But I wanted to get a paid product out the door to test whether this product has anything resembling Product Market fit, and I was able to do so within several hours.
I would love for you to check it out at W9er.cc and let me know if you have any feedback!
Thanks for reading! If you’d like an email whenever I post something new, sign up here (a few times per year at most):