Full-Stack Web Developer
Full-Stack Engineering
Ship a real, production-quality web app from database to deployed UI. Over 12 weeks you'll work in modern stacks (TypeScript + Next.js + Postgres), design APIs, manage authentication, handle file uploads, and deploy with proper CI/CD. This is the program if you want the breadth that lets you join a small team and contribute everywhere on day one. You'll learn enough of each layer to make sensible trade-offs across the stack. Topics covered: React / Next.js patterns, server actions and API design, relational data modelling, authentication and authorisation, file storage, testing strategy, CI/CD, deployment to Vercel / Railway / equivalents.
Time commitment
12-18 hours per week
Prerequisites
JavaScript or TypeScript basics (variables, functions, async/await). HTML + CSS comfort. Git basics (clone, branch, commit, push). No prior React or Next.js experience required — but if you've never built any web page before, this program will be a steep climb.
You'll leave with
A deployed full-stack application with documented architecture, working authentication, a real database schema, and a CI/CD pipeline. README good enough that a stranger could clone it and run it in 10 minutes.
What you receive
Structured weekly plan
Clear objectives, defined tasks, and concrete deliverables for every week of the program.
AI-led evaluation
Every submission is reviewed across technical proficiency, ownership, communication, and learning.
Human expert on request
Request a human expert reviewer for advanced topics, escalations, or specialised guidance.
Verifiable credentials
Formal offer letter on approval. Verifiable experience letter on completion.
The 12-week roadmap
Every week is planned before you start.
- Week 1
Next.js + Postgres setup, first deployed feature
Stand up a working Next.js 15 + Postgres app and ship one feature that exercises the full stack — UI → server action → database → re-render. Deploy it. The point of week 1 is to remove the deploy fear so you ship daily for the rest of the program.
What you'll do
- Create a new Next.js 15 app with TypeScript and Tailwind
- Add Prisma + a local Postgres (Docker or Supabase); run your first migration
- Build a simple task-list feature: list / create / delete (server actions OK)
- Deploy to Vercel; verify the deployed URL works against a hosted DB
- Write a README with local setup and deploy instructions
You hand in: Deployed URL, GitHub repo, screenshots of the feature working, and a README a stranger could follow.
- Week 2
Auth + multi-user — your first real account boundary
Add authentication to the week-1 app so each user only sees their own tasks. Pick a reasonable auth solution (NextAuth, Clerk, or hand-rolled with bcrypt + JWT). Get the data isolation right — accidentally rendering another user's data is the most common bug in week-2 work, so test for it explicitly.
What you'll do
- Pick and integrate an auth solution; document why you chose it
- Add a User model and a userId foreign key to your task model; migrate
- Gate every server action and page on the current session
- Write a manual test plan: log in as User A, create tasks, log in as User B, verify nothing leaks
- Deploy + verify the same on prod
You hand in: Updated deployed URL with auth working, GitHub diff showing the auth integration, and the manual test results showing data isolation holds.
- Week 3
Data modelling and migrations under real constraints
Take your app past toy schema. Model something with genuine relational complexity: many-to-many, soft deletes, an audit trail, and at least one rule the database enforces rather than your application code. Write forward migrations you would be willing to run on production data, and practise the rollback. The lesson is that constraints in the database are the only ones a bug cannot bypass.
What you'll do
- Extend your schema with a many-to-many relation and a status lifecycle enum
- Add database-level constraints: unique indexes, foreign keys, and one CHECK constraint
- Write a migration that backfills existing rows, and test it against seeded data
- Practise a rollback: migrate up, migrate down, verify no data is silently lost
- Add indexes for your three most common queries and show the query plan before and after
You hand in: Migration files with backfill and rollback tested, the schema diagram, and EXPLAIN output showing your indexes are used.
- Week 4
Forms, validation, and the error states nobody demos
Most of real product work is the unglamorous path: bad input, partial failures, double submits, slow networks. Build one genuinely complete form flow. Validate on both client and server from a single schema. Handle every state explicitly: empty, loading, partial, error, success, offline. Make double-submission impossible. This week is what separates a demo from a product.
What you'll do
- Share one validation schema between client and server so the rules cannot drift
- Implement every UI state explicitly, including a slow-network and a server-error state
- Make submission idempotent so a double click cannot create two records
- Preserve user input on failure; never make someone retype a long form
- Test with a throttled network and with JavaScript disabled for the critical path
You hand in: Deployed flow, a state matrix documenting every state and how it is reached, and a recording of the error paths behaving correctly.
- Week 5
Testing - unit, integration, and one real end-to-end journey
Write the tests that would let you refactor without fear. Unit tests for the logic that has edge cases, integration tests against a real database rather than mocks, and one Playwright end-to-end test covering your most important user journey. Wire them into CI so a broken build cannot merge. Aim for tests that fail when behaviour breaks, not tests that chase a coverage number.
What you'll do
- Unit-test your business logic, including the edge cases you found in week 4
- Write integration tests against a real test database, with per-test isolation
- Write one Playwright end-to-end test for signup through your core action
- Wire all three into GitHub Actions; make the build fail on a test failure
- Deliberately break a behaviour and confirm the right test catches it
You hand in: Green CI run, the test suite, and a short note on what you chose not to test and why.
- Week 6
Performance - find the real bottleneck before optimising
Measure first. Find your N+1 queries, your oversized payloads, your render-blocking resources. Fix the ones that actually matter and prove it with numbers. Learn the difference between server response time and what the user perceives. Optimising something you did not measure is how engineers waste weeks.
What you'll do
- Profile your slowest page; identify and fix every N+1 query
- Measure Core Web Vitals before and after; target LCP under 2.5s on a throttled connection
- Add caching at one layer (query, route, or CDN) and measure the actual improvement
- Reduce your largest JavaScript bundle; show the before and after analysis
- Load test one endpoint and document where it starts to degrade
You hand in: Before-and-after performance report with real numbers, the bundle analysis, and load test results naming your current ceiling.
- Week 7
File uploads and background work
Add a feature that cannot happen inside a single request: file upload with processing. Validate uploads properly, because an upload endpoint is an attack surface. Move the slow part to a background job with retries and a visible status the user can poll. Handle the job failing halfway through.
What you'll do
- Implement direct-to-storage upload with server-side type and size validation
- Reject dangerous uploads: verify content type, cap size, never trust the filename
- Process files in a background job with a retry policy and a dead-letter path
- Show live job status in the UI, including the failed state with a retry action
- Test the job crashing mid-processing and confirm no corrupt state is left behind
You hand in: Working upload-and-process feature, evidence of the validation rejecting bad files, and a demo of a failed job recovering.
- Week 8
Third-party integration and webhooks done idempotently
Integrate a real external service with webhooks - payments, email, or scheduling. Webhooks arrive out of order, arrive twice, and arrive when your database is down. Verify signatures, make every handler idempotent, and persist events before acting on them. This is the single most common source of production data corruption in young products.
What you'll do
- Integrate one external service end-to-end in sandbox or test mode
- Verify webhook signatures and reject anything unsigned or replayed
- Persist each event with its provider ID and make handlers idempotent on that ID
- Handle out-of-order delivery explicitly; do not assume sequence
- Test by replaying the same webhook five times and asserting exactly one effect
You hand in: Working integration, the replay test proving idempotency, and a written description of what happens if your app is down when a webhook fires.
- Week 9
Accessibility, responsiveness, and internationalisation
Your users are on phones, on slow networks, in other languages, and some of them use a screen reader. Make the app genuinely usable in all four cases. Keyboard-navigate every flow. Fix contrast and focus states. Extract hardcoded strings. Test on a real device, not just a resized browser window. Accessibility is not a checklist item; it is whether people can use what you built.
What you'll do
- Run an automated audit (axe or Lighthouse) and fix every serious issue
- Complete your core journey using only the keyboard, then again with a screen reader
- Fix contrast, focus indicators, form labels, and heading structure
- Test on a real phone on a throttled connection; fix what breaks
- Extract user-facing strings into a translation layer and add a second locale
You hand in: Audit report showing issues resolved, a screen-reader walkthrough recording, and the app running in a second language.
- Week 10
Observability and continuous delivery
Know when your app breaks before a user tells you. Add error tracking with source maps, structured logs with request IDs, and an uptime check. Build a deployment pipeline that runs tests, applies migrations safely, and can roll back. Then deliberately break a staging environment and practise finding it from your telemetry alone.
What you'll do
- Wire error tracking with source maps so stack traces are readable
- Add structured logging with a request ID threaded through the stack
- Set up a health endpoint and an external uptime monitor that alerts you
- Build a deploy pipeline that runs migrations safely and supports rollback
- Break something on purpose, find it using only your telemetry, and write the post-mortem
You hand in: Deployed pipeline, a live monitoring dashboard, and the post-mortem from your induced incident.
- Week 11
Security hardening review
Review your own app the way an attacker would. Check authorization on every endpoint, not just the UI routes that hide the buttons. Test for the standard failures: broken object-level authorization, injection, XSS, CSRF, secrets in the client bundle, and missing rate limits on anything that sends email or costs money. Fix what you find and document what you accepted.
What you'll do
- Enumerate every endpoint and verify server-side authorization on each
- Test object-level authorization by requesting another user's records directly by ID
- Check for XSS in every place user content is rendered, including markdown
- Confirm no secret is reachable from the client bundle; rotate anything exposed
- Add rate limiting to auth, password reset, and any endpoint that costs money
You hand in: Security review document listing what you tested, the vulnerabilities you found and fixed, and the residual risks you accepted.
- Week 12
Portfolio and handover - make it hire-worthy
Turn twelve weeks into something you can show. Write the case study with real numbers: what you built, the hard decisions, what the performance and security work actually changed. Record a demo. Write a handover doc another developer could act on. Clean the repository so a stranger can clone it and have it running in ten minutes.
What you'll do
- Write a technical case study with architecture decisions and measured results
- Record a 5-minute demo covering the core journey and one hard problem you solved
- Write a handover doc: architecture, runbook, known issues, next three priorities
- Clean the repo: README, one-command setup, seed data, no secrets in history
- Prepare three interview talking points backed by specific numbers from your work
You hand in: Published case study, demo recording, handover document, and a repo that runs from a clean clone in under ten minutes.