Wire One Real Thing
This week your portfolio stops being a poster and does something: usually a working contact form. One feature, not ten, wired end to end on free tools, and understood well enough to explain.
- A backend is just the part that remembers or does something a plain page cannot: stores a message, captures an email, runs your model.
- A portfolio whose whole job is "get me hired" with no working way to contact you is a locked door with a great sign on it.
- You do not have to build a server. Free services take a form and email you the submissions. That is the clean version of what your mentor once held together with tape, and you get it free.
Why it matters
A static portfolio tells; a portfolio with one real feature does. Wiring exactly one thing, and understanding it, is the difference between a poster and a tool, and it is the most directly employable skill in the whole track.
Brief
- Choose the one dynamic feature your portfolio actually needs: most often a working contact form or email capture; for some, a live demo of your own work or a small AI feature. One, not several.
- Wire it end to end on a free tier, with AI as your build partner. It has to genuinely work: a real submission reaches you, or the demo really runs.
- Write a short plain-words explainer: what a backend is, what your feature does, and how the data flows, in your own words.
Deliverable
Evidence of the live feature working (a real test submission that reached you, or the working demo), plus the plain-words explainer. Post it in your track thread.
Evaluation criteria (pass/revise)
- Exactly one feature, working live end to end, not several half-wired.
- It is on a free tier and genuinely functions on a real test.
- The explainer is correct, in your own words, and shows you understand the data flow.
Wire one thing, end to end
Pick the single feature your site actually needs. Wire it end to end on a free tier. Understand the data flow well enough to explain it.
Wire the one feature, then make it fail gracefully. Swap each {highlighted} bit first.
Watch out for
- Wiring three things. One feature, working, understood. Cut the rest.
- Imagining you need a server. Free form services handle it. Push back if the AI over-builds.
- Shipping a mystery. If you cannot say where a submitted message goes, you are not done yet.
What good looks like
- A real message reaches you, and you can explain how.
- The form behaves well when someone submits it empty.
- Your explainer would make sense to a friend who has never built a site.
- Backend. The part that remembers or does something a plain page cannot.
- Contact form. The form that lets someone reach you and emails you what they wrote.
- Free tier. The no-cost plan of a service. Enough for a portfolio, and the rule for this build.
- Data flow. The path a submitted message takes from the form to your inbox. Your explainer traces it.
Linked resources
HTML contact forms, no backend ↗
Add a working contact form to a static site with no server: point your form at an endpoint and the messages reach your inbox.
Google · web.devLearn Forms ↗
How to build forms that are clear, accessible, and hard to submit wrong. Pairs with making yours fail gracefully.