Proof of Concept and Learning Experiences
Testing assumptions before starting so you don't go too far down the wrong path.
Before starting my first formal "12-week year" project plan, I needed time to figure out if my chosen technology stack would help me achieve my app goals. I also wanted to test if I could use AI language models (LLMs) to help me learn and write the app code.
Sometimes, product teams and executives just want to start building. But it helps to test your core assumptions before committing all your resources. This is the same reason we test market assumptions.
Here's what I learned
Quick version:
Test your technology assumptions with simple proof of concepts. I found out my initial assumptions were wrong and had to change course.
Test your tools to find the best way to use them and discover unexpected benefits.
Try out different ways of working, even with a team of one or a small group. This helps you find the most efficient way to use your time, even if it means putting less important things off until later.
Longer version:
Technology Stack:
I first tried using Django/Python for the backend with APIs, and Svelte or React for the frontend. I wanted to test if:
I could learn enough Django and Python to build REST APIs
I could call those APIs from a separate frontend or as part of the same web server
After some experiments, I realized this was too complex for my limited time and resources. So, I decided to simplify and focus on Svelte and SvelteKit as the main technology stack. But Svelte is changing, with version 5 coming soon. So I needed to test if:
I could build my app using Svelte 5 with minimal problems, even though it's still in beta
To test this, I built a basic version of the app focusing on key features like creating, reading, updating, and deleting data. I also tested different data relationships and core navigation.
Good news – my assumptions were right, and I settled on using Svelte & SvelteKit, with Prisma for the database and Shadcn-Svelte for the component library.
AI Language Models (LLMs):
It's been over a decade since I last worked with HTML, JavaScript, and CSS. I needed help to learn quickly. While I have access to O'Reilly books, it takes time to find the right one and work through examples. I hoped to use AI chatbots to speed up learning and automate some tasks.I wanted to test if:
The latest versions of OpenAI, Claude, or Hugging Face knew enough about Svelte, JavaScript, TypeScript, and the libraries I wanted to use (Prisma and Shadcn-Svelte).
They could provide helpful feedback to write good code and explain how things work.
I could use them to automate tasks and help write the whole app, including complex business logic.
To test this, I asked the AI models to explain Svelte, how version 5 differs from 4, and about the libraries I wanted to use. I compared their answers to official docs to check for accuracy. I found that the latest Claude had the knowledge I needed.
I then used Claude to help create code for my technology stack proof of concepts. Through trial and error, I found the right way to ask for help and understand the suggested code. Claude even suggested new approaches I hadn't thought of, including ways to organize code. However, it still gives incorrect or error-prone code about 40% of the time. This means I need good backups to recover previous versions if needed. I also have to either ask follow-up questions and error codes, or rerun the query to add additional clarification questions.
I also used Claude to quickly generate new code based on working templates, replacing key elements to create variations, which helped to speed up my development efforts.
This gave me confidence to use Claude as my 'senior dev' helper for coding, and confirmed my assumption that LLM can help not only teach me the skills I need, but also speed up my development.
Other Learnings:
Beyond technology and tools, I also tested how I manage my time. I wanted to see if I could make progress on software development while meeting my full-time job duties. I tested if:
I could spend enough time on software development while also supporting marketing activities and blogging.
To test this, I organized my schedule with a best-case scenario to see if I could build proof of concept code, write draft blogs, and work on how-to videos for marketing.
I quickly found it hard to find dedicated time for coding while making good progress. Most issues came from juggling personal life and time lost switching between tasks. It takes time to refocus before becoming productive.
Based on this, I'll adjust and focus on code development and provide a bi-weekly progress summary in blog form. I'll work on how-to videos when I can, but without set deadlines. This prioritizes what I need most – a working app – while putting off marketing efforts until I'm closer to a release candidate.
With all these learnings, I'm ready to start my first 12-Week Year (Quarter) objectives, which will focus on delivering a working prototype that can demonstrate core and differentiating value, and collect market feedback, while publishing bi-weekly progress updates.
Next up is building the app and sharing my progress as I go, so stay tuned.