A BUILD-IN-PUBLIC STORY
From blank screen to a full-stack AI resource hub — auth, community, prompt library, tools directory, newsletter, and 400+ prompts — built entirely in conversation with an AI.
By Michael J. · March 2026 · oneplaceforai.com
|
20+ Sessions |
10 Days to Build |
400+ Prompts Created |
15+ Features Shipped |
The Idea
The AI space is noisy. There are thousands of tools, hundreds of thousands of prompts scattered across the internet, and no single place that brings it all together in a clean, curated way. That gap was the seed for OnePlaceForAI.com.
The concept was simple: a resource hub where people could discover AI tools, browse and copy production-ready prompts, read AI news, and connect with a community of people who use AI every day. Simple in concept — but a full-stack web application in practice.
What made this project unusual wasn’t the idea. It was how I built it.
The premise: I would build the entire site in conversation with Claude — no agency, no freelancer, no pre-built CMS. Just me describing what I wanted, and Claude writing the code.
The Approach: Build-in-Public With an AI
I want to be clear about what this project was and wasn’t. I’m not a developer. I understand technology, I know what I want, and I can read code well enough to spot when something is wrong — but I wasn’t writing PHP, SQL, and CSS from scratch. Claude was.
What I brought to the table was product vision: knowing what features mattered, what order to build them in, how the user experience should feel, and what needed to be fixed when something broke. Claude brought the technical execution.
Every feature was built through a conversation. I’d describe what I wanted, Claude would write the code, I’d test it on my server, report back what worked or broke, and we’d iterate. Across 20+ sessions spanning 10 days, that loop produced an entire production website.
The stack: PHP (server-side), MySQL (database), vanilla CSS with a custom design system, JavaScript for interactivity. Hosted on a standard shared server running Apache with phpMyAdmin for database management.
What We Built: Phase by Phase
| Phase | Date | What Was Built |
| Phase 1 | Feb 27 | Site architecture, database schema, CSS design system, homepage |
| Phase 2 | Feb 27 | Prompt Library — browse, filter, search, individual prompt pages |
| Phase 3 | Feb 27 | Full authentication system — login, register, Google OAuth, password reset |
| Phase 4 | Feb 27 | Prompt features — save, like, submit, edit/delete, Prompt of the Day |
| Phase 5 | Feb 27 | Admin panel — dashboard, user management, categories, settings |
| Phase 6 | Feb 27 | AI Tools Directory — browse, detail pages, submit, save, reviews |
| Phase 7 | Feb 28 | AI News — RSS integration, auto-fetch, article pages |
| Phase 8 | Mar 1 | Static pages — About, Contact, Privacy, Terms, admin messages inbox |
| Phase 9 | Mar 1 | Community (Reddit-style) — posts, voting, comments, channels |
| Phase 10 | Mar 2 | Affiliate tracking — /go/ redirects, click analytics dashboard |
| Phase 11 | Mar 2 | Newsletter system — weekly digest, subscribe/unsubscribe, admin send |
| Phase 12 | Mar 2-3 | Content — 400+ prompts across 17 categories added to the database |
| Phase 13 | Mar 8 | Quality audit — security review, bug fixes, schema patch |
DEEP DIVE
The Build, Feature by Feature
1. Foundation: Schema, Design System & Homepage
Every serious web project lives or dies by its foundation, and the first session set the tone for everything that followed. We started with the database schema — designing tables for users, prompts, categories, models, and tools before writing a single line of frontend code.
Alongside the schema, Claude built a custom CSS design system from scratch: CSS variables for colours, typography, spacing, and border radii; a dark theme with a black/navy surface palette; an orange-to-red gradient as the primary accent. The homepage brought it all together with a hero section, animated stats, featured prompts, and a newsletter signup.
Key decision: Building a design system first meant every page that followed had a consistent visual language. The –accent-orange, –surface, –border variables appeared in every file that came after.
2. Prompt Library
The prompt library was the core feature and the first real test of the approach. It needed to do a lot: browse prompts by category, filter by difficulty (Basic/Intermediate/Advanced), search by keyword, sort by newest or most popular, paginate results, and handle both guest and logged-in states.
Claude built the browse page, the individual prompt view page, the copy-to-clipboard API, and the like/save system — all in a single session. The most interesting challenge was the slug-based routing: rather than ugly ?id=123 URLs, every prompt got a clean /prompts/build-a-90-day-business-plan style URL.
3. Authentication System
Authentication is the feature most developers dread building, because getting it wrong has real security consequences. The system we built includes local email/password auth with bcrypt hashing, Google OAuth integration, email verification, remember-me tokens stored as hashed values in the database, password reset via email, and role-based access control (user vs admin).
Every database query uses prepared statements. Passwords are hashed with bcrypt at cost factor 12. The remember-me system uses cryptographically random tokens, not user IDs. Session handling follows secure practices throughout.
Security note: During our quality audit, we confirmed zero instances of raw user input being passed directly to SQL queries — every user-supplied value is bound via PDO prepared statements.
4. Admin Panel
A site is only as manageable as its admin tools. The admin panel we built covers: a dashboard with live stats (total users, prompts, tools, subscribers, revenue metrics), user management with role assignment and account status controls, prompt management with publish/unpublish/delete and a preview modal, tools management with featured toggle, news article management, subscriber management, and site settings.
Every admin page is protected by auth_require_admin() — a function in the auth library that checks both that the user is logged in and that their role is ‘admin’. Unauthenticated requests are redirected to the login page.
5. AI Tools Directory
The tools directory was the most complex feature in terms of database design. It introduced five new tables: tools, tool_categories, tool_tags, tool_tag_map, tool_saves, and tool_reviews. Tools could be filtered by category, pricing tier (free/freemium/paid/contact), and sorted by featured, most saved, highest rated, or newest.
Each tool got its own detail page with description, tags, AI models used, a star rating system, user reviews, related tools, and both save and visit tracking. Guests could save tools to session storage; logged-in users got saves persisted to the database.
The affiliate system built on top of this — tools with affiliate relationships got /go/tool-slug redirect URLs that logged clicks with IP, user agent, and referrer before forwarding to the affiliate link.
6. Community (Reddit-Style)
The community feature was the most ambitious single build. In one session, Claude produced a full Reddit-style forum system: channels (like subreddits), posts with rich text, upvote/downvote voting with score calculation, nested comments, post flairs, pinned posts, and a community submission page.
The voting system deserves a mention: rather than storing a simple integer score, the database tracks individual votes (user_id, post_id, vote: +1/-1) so votes can be changed and the score is always accurate. The frontend updates scores optimistically and rolls back on API errors.
7. Newsletter System
The newsletter system went through multiple iterations. The initial dark-themed HTML email was rebuilt after realising most email clients render dark backgrounds poorly — we switched to a light, table-based template compatible with Gmail, Outlook, and Apple Mail.
The final system includes: a weekly digest builder that pulls top prompts, featured tools, and recent news automatically; a subscribe/unsubscribe flow with token-based unsubscribe links; a send queue with batch sending to avoid rate limits; admin preview (view the email in-browser before sending); and a subscriber management panel.
8. Content: 400+ Prompts Across 17 Categories
Once the platform was built, we needed to fill it. Over several sessions, we generated and formatted 400+ production-ready prompts across every category on the site.
Every prompt follows the same format: a title, a short description, a full prompt_text with [PLACEHOLDER] variables the user fills in, a difficulty level, and attribution. The prompts are practical — things like ‘Build a 90-Day Business Action Plan’, ‘Write a Complete Testing Suite’, ‘Create an SEO Content Cluster Strategy’ — not toy examples.
Categories covered: Business, Marketing, Creative Writing, Technical, Education, Image Generation, Video & Audio, Productivity, Research, Casual, Writing & Content, Coding & Dev, Social Media, SEO & Growth, Email, Health & Wellness, Coaching.
What Worked Brilliantly
- Incremental building. Each session had a clear scope. ‘Build the auth system.’ ‘Build the tools directory.’ ‘Add the newsletter.’ That clarity meant sessions were productive and outputs were coherent.
- Journalled sessions. Claude maintained a rolling journal of what had been built across sessions. Starting a new session with ‘here’s where we left off’ meant we never lost context.
- The design system. Defining CSS variables in session 1 meant that every feature built afterwards inherited the same visual language automatically. Consistency came for free.
- Security-first by default. Prepared statements, password hashing, role-based access, XSS protection via htmlspecialchars — these weren’t afterthoughts, they were in the first draft.
- Speed. A complete, full-stack web application with auth, community, affiliate tracking, and a newsletter system — in 10 days. That’s not a pace a traditional development workflow could match for this budget.
What Was Harder Than Expected
- CSS conflicts. When multiple feature CSS files loaded on the same page, classes occasionally collided. Debugging these required careful inspection of which file was winning and why.
- Schema mismatches. As features evolved, the database schema needed updates that weren’t always reflected in the PHP files referencing it. The quality audit at the end caught a real example: the affiliate columns added to the tools PHP files weren’t in the original schema file.
- Email rendering. The first newsletter template looked great in a browser and broke in Outlook. Email HTML is its own discipline — table-based layouts, inline styles, no CSS variables. The rebuild to a light, table-based template took a full session.
- Long-session context. Very long sessions occasionally saw Claude lose track of a detail established earlier. The solution was regular summaries and starting fresh sessions with explicit context-setting.
What I Learned About Building With AI
Describe outcomes, not implementations
The most productive prompts were outcome-focused: ‘I want users to be able to save tools and see them in their dashboard’ — not ‘write a PHP function that INSERTs a row into tool_saves’. Describing the user experience gave Claude the context to make good implementation decisions.
Always test, always report back
The workflow that produced the best results was: Claude writes code → I deploy and test → I report exactly what happened (including error messages and screenshots) → Claude fixes it. Skipping the test step and asking for code without feedback produced lower-quality results.
The AI is the developer; you are the product manager
My job was to know what to build, in what order, and what ‘done’ looked like. Claude’s job was to figure out how to build it. That division of responsibility worked well when I respected it — and broke down when I tried to micromanage the implementation.
Quality audits matter
Asking Claude to review all the files for issues at the end of the project caught the schema mismatch that would have caused a production error on first deploy. Building in a review step — not just shipping — is as important in AI-assisted development as it is in traditional development.
What’s Next for OnePlaceForAI
The site is live and growing. Here’s what’s on the roadmap:
- Prompt ratings and user reviews
- AI model comparison pages
- User profile pages with public prompt portfolios
- Weekly ‘Prompt of the Week’ email feature
- API access for prompts (for developers)
- Expanded tool categories — agents, voice AI, video generation
- Monetisation through featured listings and affiliate partnerships
Final Thoughts
The question I get asked most about this project is: ‘But did you really build it, or did Claude?’
I think it’s the wrong question. A carpenter doesn’t stop being a carpenter because they use a power saw instead of a hand saw. The tool changes; the vision, the judgement, and the craftsmanship remain human.
What I built was a product. Claude helped me build it faster than I could have otherwise. The decisions about what to build, what mattered to users, what the experience should feel like — those were mine. The PHP and SQL were Claude’s.
If you’re sitting on a web project idea and you’ve been waiting until you ‘learn to code’ — you might be waiting for the wrong thing. The barrier to building has changed. What matters now is knowing what to build and being willing to iterate until it’s right.
Visit the site: OnePlaceForAI.com — prompts, tools, news, and community for AI users.
© 2026 Michael J. — OnePlaceForAI.com — All rights reserved.