In 48 hours, a beginner can build and publish a one-page web tool that does one job for one kind of person: paste something in, get something useful out. Skip logins, databases and payments, pick a problem you or someone near you actually has, and spend the last few hours deploying it and writing down what broke.
What can you build with AI in 48 hours?
More than you'd guess, and less than you'd hope. The realistic answer for a beginner is a one-page tool: a single web page that takes some input, does one thing to it, and shows a result. A dilution calculator for your chem lab. A page that turns pasted course times into a weekly grid and flags conflicts. A flashcard drill that runs on terms you paste in.
What you probably can't finish in 48 hours, at least not well, is anything with accounts, a shared database, payments or a mobile app store listing. Those aren't impossible. They just eat the weekend before you've shown the tool to a single person.
Why one page? What experienced builders agree on
The people who build small tools with AI most often keep giving the same advice, from different directions.
Keep it to one file. Simon Willison, a software developer who writes widely about AI tools, has built more than 150 single-file "HTML tools" over about two years, almost all written by AI models. His patterns: HTML, CSS and JavaScript in one file, no framework that needs a build step, dependencies loaded from a CDN, and a few hundred lines at most. Small enough that if it breaks, you can have the AI rewrite it in minutes.
Cut the scope until it fits the time you have. Andrew Ng, writing in DeepLearning.AI's newsletter The Batch, describes building a public-speaking practice tool in a couple of spare hours on a Saturday. He got there by cutting: one simulated audience member instead of a crowd, a person behind the scenes choosing reactions instead of AI, a simple 2D avatar. His rule is to shrink the idea until you can build something in the time you actually have.
Start from a problem someone actually has. Paul Graham's essay How to Get Startup Ideas is about companies, not weekend projects, but its test carries over: can you name who wants this right now? He warns against "made-up" ideas that sound plausible but that nobody would use, and suggests you "live in the future and build what seems interesting."
Put it somewhere public. Willison hosts his tools on GitHub Pages. GitHub's quickstart walks through it in a few steps, and notes that changes can take up to 10 minutes to publish.
Where the advice runs out
These sources mostly talk past one another on one point. Willison builds tools for himself, Ng builds a rough prototype to get early feedback, and Graham is talking about ideas worth years of your life. None of them says what a beginner should do when their only deadline is 48 hours and someone else will look at the result.
They're also quiet on two things that matter for a first build:
- Showing it to a real person. A tool nobody has opened except you is untested, however clean the code.
- Writing down what went wrong. Ng mentions that feedback on his crude prototype changed his idea, but none of them treats the record of what broke as part of the work. For a student, that record is often what makes the project believable later.
That's where the practical answer below fills in.
One-page tool ideas for beginners
Each of these needs no login, no server and no database. Swap in your own campus, course or club.
| Idea | Who has the problem | You paste or type | It shows |
|---|---|---|---|
| Lab dilution calculator | Students in your intro chem lab | Stock and target concentrations, volume | How much to pipette, step by step |
| Schedule conflict checker | Anyone picking classes | Course times copied from the registrar page | A weekly grid with clashes highlighted |
| Flashcard drill | Classmates before a vocab-heavy exam | A list of terms and definitions | Shuffled cards, with progress saved in the browser |
| Citation fixer | A course that requires one specific style | A messy reference | The reference in the required format |
| Shuttle "next departure" page | Riders on one campus route | Nothing; the timetable is built in | The next three departures from where you are |
| Recipe scaler | Roommates cooking in a dorm kitchen | A recipe and the number of people | Scaled amounts, converted to the units you own |
Two warnings that save weekends:
- Don't put an AI API key in a public page. Anyone can open the page source and copy it. Tools that work without a key are the safer first build.
- Don't collect other people's personal data. No forms asking for names, emails or student IDs. If the tool needs to remember something, keep it in the user's own browser.
A 48-hour plan that ends with something live
- Hour 0–2: pick the problem. Write one sentence: "[Who] needs to [do what] and currently [does it badly how]." If you can't name a real person, pick another idea.
- Hour 2–3: describe it to the AI. Ask an AI chat tool or coding assistant for a single HTML file that does the one job. Say what goes in and what should come out. Ask for no frameworks.
- Hour 3–12: make it work. Test it with real inputs, including messy ones. When it's wrong, paste the error or describe exactly what happened.
- Hour 12–20: deploy it. Put it on a public link now, not on Sunday night. Open it on your phone.
- Hour 20–40: show it to two or three people who have the problem. Watch them use it without explaining. Fix the one thing that confused them most.
- Hour 40–48: write it up. What it does, who it's for, what went wrong and how you fixed it. Keep the AI conversation or commit history as evidence.
If you're behind at hour 20, cut a feature, not the deploy.
How this connects to STARC
This isn't a hypothetical for us. Applying to STARC's one-person company cohort includes a 48-hour task: use any AI tool to build a one-page tool that anyone can open, plus a note of up to 300 words on what went wrong and how you fixed it. Rough is fine. Applications are reviewed by a person, with school names removed, and we look at three things: did you ship, is your account honest, and is it a real problem for real people. The FAQ covers who can apply and the time commitment.
You don't need to apply anywhere to use the plan above. A working one-page tool and an honest note about building it are worth having either way.
The short version
In 48 hours, build one page that does one job for one kind of person. Skip accounts, databases, payments and API keys in the page. Deploy early, show it to someone who has the problem, and write down what broke. That's a real first project.
Related questions
Do I need to know how to code to build a one-page tool with AI?
No. You describe what you want to an AI chat tool or coding assistant, and it writes the HTML, CSS and JavaScript. You do need to test it yourself, notice when it's wrong and ask for fixes.
Where do I put the tool so other people can open it?
A static host such as GitHub Pages works for a single HTML file. GitHub's own quickstart notes that changes can take up to 10 minutes to go live, so don't leave deploying to the last minute.
Can my 48-hour tool call an AI model like ChatGPT inside the page?
Be careful. If you paste an API key into a public page, anyone can read it and use it. For a first 48-hour build, prefer a tool that works without a key, or keep the AI part on your side while you build.
What if my tool is too simple to impress anyone?
Simple is the point. A small tool that works, that someone uses, and that comes with an honest note about what went wrong says more than a big unfinished one.
Want to build your own product?
The OPC cohort: 12 students, 8 weeks, one real product with real users.
Follow STARC on X. New posts, what we're building, and the questions students send us: @Starc_Institute
Follow on XLast updated: 2026-10-30. Written by the STARC team. Rules quoted here come from our how it works page; if they change, this post is updated.
More questions
Should I put vibe coding on my resume as a student?
Should you put vibe coding on your resume? Why the phrase is risky, what to write instead, and how to show AI-assisted work honestly.
Sophomore or junior: should I do research or build a product, and how do I split my time?
Research or your own product in sophomore or junior year? Pick by your next step, give one a main slot, and plan around summer and REU deadlines.
How do I find my first 10 users on campus who aren't my friends?
How a college student can find 10 real users on campus beyond friends: pick a narrow group, go where it gathers, and ask the right way.