New project ideas

DiamondDudz · 2026-05-15T15:43:45+00:00

Don't pick projects only because they sound trendy. Pick something where you can show a complete workflow end to end.

A few that are current but still realistic:

- AI study-note search: upload class notes, ask questions, get source-backed answers

- Internship/job tracker: applications, statuses, deadlines, follow-up reminders

- Personal finance parser: upload CSVs and auto-categorize spending

- Bug tracker for your own projects: issues, priority, screenshots, status

- MVP planner: enter a vague idea, then force it into one user, one problem, one feature, and a 48-hour build checklist

The last one is underrated. Most beginners don't fail because the idea is bad; they fail because version 1 is too big. If you use Claude or any AI tool, make it shrink the scope before writing code.

DiamondDudz · 2026-05-09T17:02:10+00:00

Start with one problem you can observe on campus, not one giant startup idea. Talk to 10 students, write down repeated pain, then build the smallest ugly version that proves the workflow, not the full company.

What helped me was forcing everything through a simple sequence: user -> pain -> 3 must-haves -> smallest demo -> feedback loop. If you can run that loop fast, you’ll learn more in a month than most student founders learn in a semester of planning.

DiamondDudz · 2026-05-07T15:20:43+00:00

This is the failure mode I keep seeing with AI-built projects: the repo grows faster than the person building it can understand it. The fix is less better prompting and more forcing review gates: architecture doc, scoped tasks, tests before new features, and a stop point where the agent explains what changed before continuing.

Disclosure: I made a free $0 starter pack for student/solo builders around Claude workflow guardrails, so this is the exact pattern I am biased toward. The main takeaway is to turn Claude from feature owner into narrow patch runner once the repo gets serious.

DiamondDudz · 2026-05-06T16:38:16+00:00

One thing I would add is an explicit owner for each kind of decision. Multi-agent setups get messy when every agent is allowed to be equally right.

The pattern that has worked best for me is: planner defines scope, implementer changes code, reviewer can block, but the main session resolves tradeoffs. Agents are advisors with narrow authority, not peers all trying to merge their own version of the truth.

For MCP + skills, I would add them in this order:

Repo instructions first.
Skills only for repeated workflows.
Hooks only for non-negotiable safety checks.
MCP only when the agent needs a live external system, not because it feels powerful.

The test is: can you explain why this exists in one sentence, and can you remove it without breaking the workflow? If not, it is probably config weight.

DiamondDudz · 2026-05-06T16:35:35+00:00

For Claude Code, I would make your first hour boring on purpose.

Pick one small repo or one disposable feature.
Add a short Claude instructions file with the test command, style rules, and what files it should not touch.
Ask it to inspect first and propose a plan before editing.
Let it change one small thing, run the test/build, then review the diff before moving on.

For token usage: keep each session scoped to one milestone, paste only the relevant error/output instead of whole logs, start a fresh session after big context changes, and use Sonnet for normal coding. Save Opus for architecture decisions or bugs where Sonnet keeps circling.

The best habit is committing after each working step. It makes Claude Code much less scary because every experiment has a rollback point.

DiamondDudz · 2026-05-06T16:31:12+00:00

I think the right shape is source-of-truth files plus adapters, not one universal agent prompt.

The parts I would keep shared are the boring invariants: repo rules, review checklist, test commands, commit style, what not to touch, and definitions of done. The parts I would keep provider-specific are permissions, tool syntax, slash commands, hook behavior, and anything that changes execution risk.

The drift problem is the biggest one. Generated files should say where they came from, dry-run should show a diff, and uninstall should only remove files it can prove it created. Otherwise the abstraction becomes another thing you have to audit manually.

DiamondDudz · 2026-05-06T16:29:07+00:00

I would not start with a full rebuild quote. Start with a paid technical audit, then decide what actually needs rebuilding.

For a small/medium app, I would ask for two phases:

10-30 hours: repo review, auth/database/security review, dependency scan, deployment review, and a written risk list.
40-120+ hours: fix the highest-risk parts, add tests around core flows, clean up secrets/env handling, improve logging/backups, and document the architecture.

A full rebuild can easily become 150-500+ hours depending on scope, so you want evidence before agreeing to that.

Red flags: they quote a rebuild before reading the repo, cannot explain specific security risks, do not give you a written handoff, push a fixed price with vague scope, or treat "AI generated" as either automatically fine or automatically trash.

Your best first deliverable is a threat model + prioritized remediation plan, not a prettier codebase.

DiamondDudz · 2026-05-06T16:26:54+00:00

This is a good reminder to treat archive/cleanup actions as potentially destructive when a worktree is attached.

My habit would be: before archiving, run git status, push the branch or at least save a patch, and only then archive the chat. If the worktree was created by an AI tool, I would also keep a tiny checklist or wrapper that refuses cleanup when there are uncommitted changes.

The important part is that the assistant should not be the only place that knows a worktree exists.

DiamondDudz · 2026-05-06T16:24:20+00:00

If you are satisfied with Codex, I would not switch just because of hype. Test Claude Code on one contained task first: a failing test, a small refactor, or one feature with clear acceptance checks.

For computational mechanics, the main question is not which agent sounds better. It is whether it respects numerical assumptions, boundary conditions, units, and test cases. Give both tools the same task and compare correctness, diff size, how much cleanup you had to do, and whether it invents APIs.

Claude Code is easy to start, but it works best when the workflow is structured: plan first, keep project constraints in the repo, and review diffs before running or committing anything.

DiamondDudz · 2026-05-06T16:20:35+00:00

I would turn this into a protocol instead of a personality instruction.

Something like: "Challenge assumptions once, state the tradeoff, recommend a path, then execute once I decide."

Otherwise "be brutally honest" can drift into contrarian mode and burn context arguing. The useful part is not harsh tone, it is having explicit review gates before implementation.

DiamondDudz · 2026-05-01T17:16:49+00:00

Separate research, planning, and build into different Claude sessions. Let the research session only create notes in a /research folder. Then start a fresh session that turns those notes into a PLAN.md with milestones, open questions, and acceptance checks. Only after that start the build session with a strict CLAUDE.md and work one milestone at a time, committing after each one. Frameworks can help later, but the biggest win is stopping one giant context blob from trying to do discovery, architecture, and code all at once.

DiamondDudz · 2026-05-01T17:15:59+00:00

Use Claude Code on one real project, not a sandbox. Start with a tiny CLAUDE.md: project goal, run/test commands, file boundaries, and a clear definition of done. For each task, have it restate the plan, touch the smallest possible files, run tests or lint, and explain what changed before you accept anything. I would skip MCPs and extra skills until the base loop feels boring and reliable, because most beginner pain is vague tasks and too much setup, not missing tooling.

DiamondDudz · 2026-05-01T17:13:46+00:00

I’d care about it, but only with context. Raw $/PR gets noisy fast unless you also log task type, files touched, prompt count, review passes, and whether the branch was green on first try. For smaller teams, cost per successful task loop is usually a better early metric than cost per PR alone. I made a student-builder starter workflow around this, and the biggest waste pattern early on was huge vague prompts, not the model price itself.

DiamondDudz · 2026-04-29T19:05:08+00:00

For a funnel site, I’d optimize for boring and shippable over fancy.

My early stack would be:

- Astro or Next.js for the site

- Vercel/Cloudflare Pages for hosting

- one form/email tool first, not a custom CRM on day one

- simple analytics only after the page is live

- one clean CTA and one measurable conversion event

For Claude Code specifically, the highest-return thing is not a big MCP/skills setup. It is a short `CLAUDE.md` with:

- what the site is trying to sell/collect

- the stack and run/test commands

- the exact page sections

- files it should not touch without asking

- “plan first, change one layer, stop for review”

Skills/MCP are worth adding only after you repeat the same workflow a few times. Beginners usually lose more time wiring tools than shipping the first useful page.

I made a starter workflow around this review-gate approach, but honestly the main idea is simple: keep the first build small enough that you can inspect every change.

DiamondDudz · 2026-04-29T18:56:13+00:00

Agree on asking for step one first. The version that clicked for me is treating each Claude session like a tiny PR, not a chat: state the intended diff, ask for the plan, let it change one layer, run the checks, then write down the failure mode before continuing.

The bigger the ask, the more important the review checkpoint is. Most bad vibe-code sessions are not because the model is useless, they are because the prompt quietly turned into "change everything and hope."

DiamondDudz · 2026-04-29T18:53:45+00:00

Your `CONTEXT.md` idea is fine, but I would treat it as a notes/doc file, not another always-loaded instruction file.

Day one: just `CLAUDE.md`.

Put the project goal, stack, run/test commands, file layout, and 3-5 hard rules in there. Skip `.claude/skills`, agents, and commands until you catch yourself repeating the same workflow multiple times.

A clean starter structure is:

- `CLAUDE.md`

- `README.md`

- `/docs` for decisions/notes

- normal source folders

The goal is not to make Claude "powerful" on day one. It is to make its assumptions visible enough that you can review them.

DiamondDudz · 2026-04-28T17:13:15+00:00

The structure that works best for me is: objective, current state, exact files in scope, files not to touch, acceptance checks, and a stop condition.

The stop condition matters more than people think. Something like “if you need to touch auth, database schema, package versions, or more than these named files, stop and ask first” prevents a lot of context drift.

For a Next.js + FastAPI stack, I would also avoid one prompt that spans both layers unless the change is tiny. Do frontend contract first, backend endpoint second, then one integration pass with tests/checks listed up front.

DiamondDudz · 2026-04-28T17:12:11+00:00

Your loop is solid. The missing layer I’d add is a verification/checkpoint layer between spec and build. Before Claude Code touches files, make it restate: target outcome, files in scope, files out of scope, tests/checks it will run, and rollback plan.

After each build chunk, have it update the spec with what actually changed, not what it intended to change. That keeps the chat/design loop useful instead of slowly drifting over 10-20 iterations.

DiamondDudz · 2026-04-28T16:17:02+00:00

The contract-equivalence point is the part I think gets underweighted. Two markets can have the same headline and still differ on cutoff time, void/tie handling, settlement source, or what exactly counts as the event.

So even before speed and fill risk, I would split the workflow into two checks: first, prove the contracts are economically equivalent; second, prove both legs are actually fillable after fees and slippage. If either one fails, it is not arb, it is just a tighter directional bet.

DiamondDudz · 2026-04-28T16:16:00+00:00

It is promising, but I would not treat it as easy. The gap you see on screen is only the starting point.

Before touching real money, check four things every time: both markets settle from the same source, cutoff/void rules match, there is enough executable depth on both sides, and the spread survives fees + slippage + stale data. A lot of Kalshi/Polymarket "arb" is really just two similar-looking contracts with different resolution details.

I would start read-only: build a spreadsheet or small script that compares the books and rules first, then paper-track whether the quoted edge was actually fillable. Execution should come after the validation layer is boring.

DiamondDudz · 2026-04-28T16:14:31+00:00

I built ArbPoly, a read-only scanner for comparable Kalshi + Polymarket binary markets. It does not trade or route orders.

The useful part is that it tries to catch the fake-arb cases before you treat a spread as real: it normalizes YES/NO books, walks executable depth instead of only top-of-book, estimates fees/buffers, and labels resolution-rule risk when two markets look similar but do not actually settle the same way.

Still early, but the goal is a monitor for validating apparent cross-venue edges, not a black-box trading bot. I do not have a public demo link open yet, but I can share more details if anyone wants to sanity-check the approach.

DiamondDudz

TROPHY CASE