Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did.

Tech / product concept summary

• Core idea: Most “personal software” ideas can be built without memorizing an entire software stack. The video presents five “software shapes” that cover most use cases, then maps those shapes to which AI builders/tools to use.

Personal software examples (use-case driven)

• Ferry / arrival app: Instead of relying on unreliable timetables or paid live feeds, the creator builds a setup using:

  • AIS (ship radio broadcasts)
  • an antenna/receiver
  • a Raspberry Pi that listens, stores recent data, computes arrivals, and displays results on a phone.

• House maintenance app: A web app tailored to a specific household that:

  • pulls info from appliance labels, manuals, photos, and service dates/history
  • supports shared records between two people
  • works well on phones with reminders/tasks and troubleshooting instructions.

---

The “five software shapes” (main framework)

1. Local tool

   • Runs on one computer; uses files or a tiny local DB.
   • For personal-only utilities (e.g., document organizer, photo renamer).

2. Web app

   • Runs in a browser (often addable to a phone home screen).
   • Recommended default for most personal software because it’s shareable without app-store overhead.

3. Native phone app

   • Needed when you require deeper phone features (push notification reliability, Bluetooth, background location, NFC) or app-store distribution.
   • More work due to build/signing and store review.

4. Background service

   • No UI; runs on a schedule or event.
   • Examples: poll a public record, process incoming files, alert on sensor thresholds.

5. Hardware project

   • Software lives near physical inputs/outputs.
   • Common components:
     • Raspberry Pi (general purpose)
     • ESP32/ESPHome (single sensor/device)
     • Home Assistant (integrating existing smart-home devices)

---

Which tools to use (builders / agents / stack guidance)

Fastest path: hosted AI builders (for quickest web apps)

• Lovable (recommended starting point for nontechnical builders)

  • Builder: describe the app → it creates a project, previews, and publishes.
  • Provides a managed dev environment (avoids installing languages/servers).
  • Decision point: where data/auth lives
    • Lovable Cloud = easiest (managed DB + login)
    • Supabase = more setup; uses Postgres standard and keeps data/auth in a separate service for portability/control

• Mentions other hosted/quick builder options in the same category:

  • Replet
  • Bolt

More control / more moving parts

• Replit

  • Suitable when you need more than a web interface (e.g., Python, always-running server, scheduled jobs).
  • Convenience: builder controls environment + DB + runtime + publish step.
  • Tradeoff: increases coupling to one service.

• Bolt

  • Quick full-stack web app with interface, DB, auth, storage, and publishing in one environment.

Coding-agent + modular stack (more advanced but beginner-accessible)

• Use a coding agent running with access to project files + separate services:

  • Codeex or Claude Code with GitHub (and GitHub Desktop) for source versioning
  • Supabase for database/auth/storage
  • Vercel for hosting + preview links

• Goal: separate concerns so you can swap model/host/interface without rewriting data pipelines (e.g., interface changes vs moving household records).

Models vs agents (important distinction)

• Model: the reasoning/code capability layer (e.g., OpenAI/Claude-style models, or open-source like GLM 5.2/5.3).
• Coding agent: operates on your project folder, runs code locally, reads errors, iterates.
• Hosted builder: wraps the agent with an environment + publish button.
• Advice: don’t mix multiple agents just because it’s “cool”; start with one environment.

---

Hardware + integration tooling (sensor-to-app patterns)

• Ferry example stack

  • AIS receiver/antenna → Raspberry Pi → SQLite for recent vessel data → local page on Pi.

• Remote access without exposing Pi to the internet

  • Use Tailcale to securely connect approved devices to the home-hosted page.

• Smart-home alternatives

  • Start with Home Assistant if devices already exist.
  • For custom sensor reading: ESP32 with ESPHome.

• Wiring/help via agents

  • Coding agents can interpret photos of wiring/boards to identify pins, explain components, and troubleshoot.

---

Native phone app path (when required)

• Recommended approach: Expo + Superbase backend + Expo’s app services.
• Expo can build both iOS and Android from one project, handling signing/packaging.
• Still requires Apple/Google developer accounts and passing store review.
• Recommendation: validate as a private web app first unless phone-specific capability is unavoidable (to avoid “app store tax” during early validation).

---

Safety, privacy, portability, and avoiding “vibe coding” traps

• Warns models may:

  • choose databases without explaining tradeoffs
  • add paid services
  • make things public unintentionally
  • place sensitive data incorrectly

• Proposed solution: shift model role so it behaves like a builder partner that reveals choices, not just “builds.”

“Durable truth” files (guides agents/models read)

1. project.mmarkdown – who it’s for, what changes, where it runs, what must stay private
2. decisions.mmarkdown – options, recommendation, and rationale for cost/data/access/deployment/portability
3. scenarios.mmarkdown – real user/test scenarios (e.g., “photo appliance → correct manual → create maintenance task”) for validation
4. agents.mmarkdown / claude.mmarkdown – tool-specific instructions (ask before costly/public/destructive changes, explain in plain English, present 2–3 options)

Security practices

• Keep API keys/secrets in host secret settings (e.g., Vercel secret store), not in code/screenshots/threads.
• Enforce access control at the database level (interface hiding is not enough).
• Use managed logins (avoid inventing credential storage).

Backup/testing and risk-based approach

• Emphasize backup + restore tests.
• Start without sensitive info; raise security level as risk increases.
• Get review for apps involving payments/children/medical/legal data.

---

Testing guidance (review/tutorial emphasis)

• “Write situations that matter and try them on the real devices.”
• Don’t rely solely on agent completion claims.

Example test cases for the house app

• Can you photograph an appliance and create the correct record?
• Does it preserve the model number?
• Can both spouses see and use the shared view?
• Does “complete sync” work across phones?
• What happens when photo/manual is unreadable? (unhappy paths)

---

Tools built / community resources (for getting started)

• Mentions community + Substack/Slack (support for builders).
• Mentions his own tools:
  • Open Brain: store “personal context” that databases struggle with (less-structured reasoning context like technician notes/why you chose a part)
  • Open Skills: reusable builder behaviors (repeatable instructions like protecting secrets, preserving Git history, checking real scenarios)
  • Open Engine: handoff/work movement across tools/agents/persons without retelling context
  • Ringer: advanced multi-agent orchestration with supervision and change definition (useful for complex delegated work; not for first project)

---

First-hour action plan (practical tutorial steps)

1. Write down the one long-desired wish.
2. Describe “what happens now” vs “what should happen instead.”
3. Identify the needed input/signal.
4. Specify where results should appear (screen), who sees it, and consequences if it fails.
5. Choose a building environment:
   • default to Lovable for first web app
   • modular agent stack if you need more portability/control
   • Home Assistant / Raspberry Pi / ESP32 if hardware/sensors are involved
6. Demand plain-English explanations and major-choice disclosures from the agent.

---

Main speaker / sources

• Speaker: Nate B. Jones (host/creator of the video)

Referenced external products/services

• Lovable, Replit, Bolt
• Codeex, Claude Code
• GLM (GLM 5.2 / 5.3)
• Supabase / Firebase
• GitHub, GitHub Desktop
• Vercel
• Raspberry Pi
• ESP32 / ESPHome
• Home Assistant
• SQLite
• Tailcale
• Expo (with Expo Application Services)
• OpenAI/Claude-style model ecosystems (general references)