Project 14 — A Real Internet-Aware Application (FINAL)

“Whatever you do, work heartily, as for the Lord and not for men.” — Colossians 3:23

Chapter: 16 — Final Review and Capstone Due: End of Week 16 — a take-home build, culminating in a 60-minute live integration session Submit: A link to your code — a public GitHub repository — containing all required deliverables (see Submission). See Appendix A for the local toolchain + git workflow and Appendix C for the agentic-AI toolkit and rules.

Allowed (take-home build):

• Agentic AI is ON. Direct it freely — for module bodies, scaffolding, glue, and conventional code. Every delegation goes in agent-log.txt.
• The open internet, the official docs for your stack, your own past project files.
• Your full local toolchain: Node, Python/FastAPI, the database engines, git, a real editor.

Required (no exceptions):

• AI (Phase 2): agentic AI is ON and an agent-log.txt is REQUIRED — every task delegated, what the agent did, where it was wrong, and where you intervened.
• The architecture decisions, the stack choice, the data model, and the constraint analysis are yours. The agent builds modules; you decide which modules exist and why. A submission whose architecture was clearly chosen by the agent will not pass the live defense.

The Setup

You have spent sixteen weeks becoming a software architect.

Phase 1: you learned the cost of every choice — arrays, linked lists, stacks, queues, hash tables, trees, graphs, and threads, built by hand and measured. Phase 2: you built outward into the internet — a JSON API in Node and again in FastAPI, persistence in SQLite, Postgres, and Mongo, a front end that talks to your own API, the architect’s method that turns constraints into a chosen stack, and the discipline of directing agentic AI without surrendering the judgment.

The capstone asks you to do all of it, on a real full-stack application of your choice, with the architecture decided and defended.

This is exactly the kind of application a working software engineer ships in their first months on a real team — a backend, a database, a web front end, and the seams between them — except that you are doing it alone, with an agent as your power tool. That you can build, by yourself in a take-home week, what recently took a small team a quarter, is the point of the entire sequence. The rest of your career is doing variants of this: larger, longer-lived, with more constraints. The shape is the same. You already know the shape.

This is the last project in the book.

Learning Targets

By completing this project, you will demonstrate that you can:

• Turn real constraints into a chosen stack, and justify every choice against those constraints (the thesis — Ch 1, 15).
• Stand up a backend HTTP server exposing a JSON API in Node or FastAPI (Ch 9, 10).
• Choose and justify a database (SQLite, Postgres, or Mongo) and persist data through it correctly, with parameterized queries (Ch 11–13).
• Build a reasonable web front end that talks to your API with fetch() (Ch 14).
• Architect the whole system — boxes, arrows, seams — and document it (Ch 15).
• Direct agentic AI to build modules while keeping every judgment in your own hands, and log it honestly (all of Phase 2; honesty from Coding 2 Ch 14).
• Defend your architecture and one hard decision live, under questioning.

The Approved Scope List

Pick one. Each is roughly the same size and is genuinely full-stack at the Normal tier. Pick the one whose shape you can already see. All are church-adjacent because that is this library’s frame; all are real, useful, and buildable in a take-home week.

Scope 1 — Memory-Verse Trainer

Store verses (reference, text). The front end shows one to memorize, lets you mark it “learned,” and tracks progress. (One resource: a verse, with a learned flag.)

Scope 2 — Prayer-Request Board

Store prayer requests (title, body, created_at, answered). The front end lists open requests, lets you add one, and lets you mark one answered. (One resource: a request.)

Scope 3 — Small-Group Scheduler

Store sessions (topic, date, location). The front end lists upcoming sessions and lets a leader add one. (Natural Medium-tier second resource: attendees, related to a session.)

Scope 4 — Sermon-Note Indexer

Store sermon notes (title, date, body). The front end lists notes and supports keyword search. (Genuinely document-shaped — a natural place to defend a relational-vs-document decision at Hard tier.)

Scope 5 — Reading-Plan Tracker

Store a reading plan (day, passage) and a per-day “completed” flag. The front end shows today’s reading and lets you mark days complete, tracking a streak. (Natural Medium-tier second resource: plans, with days belonging to a plan.)

A direct word, as with every project that touches the apologetics frame:

These scopes are tools, not theology. A memory-verse trainer is not a devotional practice; it is a small program that happens to use verse data. A prayer-request board is not the prayer of the church; it is a list with a backend.

Coach’s Note (confessional Lutheran framing) — The scope list is church-adjacent because the LCMS audience this book serves has natural use for these tools. None of them is a substitute for the means of grace — the Word and the Sacraments. They are small assists for the ordinary disciplines of Christian life, built well in service to a neighbor. That is vocation (Ephesians 2:10), not a replacement for the Divine Service. Build the tool. Use it in its proper, small, faithful role.

Normal Tier

Goal: Ship one scope as a working full-stack application, with the architecture written first and defended live.

Required deliverables

1. architecture.docx — written FIRST, before any code. This is graded most of all. One page. It must contain:

   • Constraints — who uses it, how many, the key queries, the consistency needs, the scale, the team. Five honest bullets.
   • Chosen stack — backend (Node or FastAPI), database (SQLite or Postgres or Mongo), front end — each with a one-line, constraint-based justification. “Because the constraint says X” — not “because it’s popular.” This is the thesis. It is the heart of the grade.
   • System drawing — boxes and arrows, browser → API → store, with the seams labeled (and your CORS / same-origin decision named).
   • Data design — the schema (or document shape): tables/collections, fields, types, primary key, relationships, any index and why.

2. A backend server (Node OR FastAPI) exposing a JSON API. At minimum GET (list) and POST (create) for your resource, with correct status codes (200, 201, 400, 404). Exception handling at every I/O boundary — server, database. Malformed input returns a clean 400, not a crash.

3. Persistence in your chosen, justified database (SQLite, Postgres, or Mongo). All queries parameterized — never string-concatenated (injection). The data must survive a server restart (prove it: create, restart, read back).

4. A reasonable web front end (HTML/CSS/JS) that talks to your API with fetch(). It must list your resource and create a new one through the API. “Reasonable,” not “beautiful” — usable and honest beats pretty and broken.

5. agent-log.txt — every task you delegated to agentic AI, in order: what you delegated, what the agent built, where it was wrong, and what you decided. Logged in real time. Use the template in code/agent-log-template.txt. At least 2 modules in your final code must have been agent-built, identifiable from the log.

6. reflection.docx — 250–450 words. Honest. Specific. Answers:

   • What the right tool turned out to be, and why (revisit your architecture-doc justifications — were they right?).
   • One specific moment the agent worked well, and one specific moment it was wrong and you caught it.
   • One thing you would architect differently next time.

7. A header comment block at the top of your main backend file:

   /*
    * Project 14 — Capstone: <Scope Name>
    *
    * Tier targeted:   Normal / Medium / Hard
    * Stack:           <backend> + <database> + <front end>
    * Time used:       <e.g., 9 hours over the week>
    * Endpoints:       <count>
    * Agent modules:   <count> of <total>
    * Hardest call:    <one phrase — the decision you most had to make yourself>
    */

Normal-tier rubric (out of 100)

The architecture document is 35 of the 100 points (the two architecture.docx rows). The code is 35. The agent log and reflection are 20. The framing is deliberate: you are graded as the architect, not the typist.

Medium Tier (+up to 25% extra credit)

M1. A second related resource

Add a second resource with a real relationship to the first (e.g., attendees belonging to a session; days belonging to a plan). Model the relationship in your data layer (a foreign key, or an embedded sub-document if you chose Mongo — and that choice is itself worth defending). Expose CRUD for it through the API.

M2. A joined front-end view

Add a front-end view that shows the two resources together — the session with its attendees, the plan with its days and completion. The join can happen in the query or in the front end; say which in your architecture doc and why.

M3. End-to-end input validation

Validate input on both ends: the front end blocks obviously bad input (empty fields, bad dates) and the backend re-validates and returns a clean 400 (or 409 on a constraint violation) — because a front-end check is a convenience, never a security boundary.

Medium-tier additional points (+up to +25)

• Second resource modeled with a real relationship, CRUD exposed: +10
• Joined front-end view works end to end: +10
• Validation on both ends, backend returns correct status codes: +5

Hard Tier (+up to 25% additional extra credit)

One genuinely hard, judgment-requiring feature an agent cannot spec for you. Pick one of H1–H3. The defining mark of all three: the agent can write the code once you’ve decided, but it cannot make the decision — and you will defend the decision live. “The agent suggested it” is an automatic fail on this tier.

H1. A concurrency-safe operation

Identify an operation that breaks under concurrent access — two leaders marking the same attendee, a double-submit creating duplicate rows, a non-atomic read-modify-write streak update. Make it correct: a transaction, a unique constraint with clean violation handling, or an atomic update. Demonstrate the race (a small script firing concurrent requests showing the bug), then show your fix closing it. Tie it back to Week 8 (threads/event loop) and Week 12 (transactions). Defend why this operation needed protection and others didn’t.

H2. A chosen index, with a measured justification

Pick a query your app runs often. Populate the table with enough rows that it matters (tens of thousands). Measure the query time. Add a deliberately chosen index. Measure again. Report both numbers, the speedup, and the space cost of the index. Relate it directly to the tree/hash tradeoff from Weeks 5–6 — an index is one of those structures, chosen. Defend why this column and this index type, and name the workload under which the index would not be worth its space.

H3. A relational-vs-document decision, baked into the data layer

For a genuinely shape-ambiguous part of your data (sermon notes with arbitrary nested structure; entries with varying fields), make a deliberate relational-vs-document choice and build it that way. Document, side by side, what your choice makes easy and what it makes hard, addressing the denormalization tradeoff (duplicated data vs join cost). Defend the conditions under which you’d flip your answer. This is the architect’s memo of Week 13, made real in code.

Hard-tier additional points (+up to +25)

• The hard feature works correctly and is genuinely judgment-requiring: +15
• The measurement / demonstration is real (numbers, a reproducible script): +5
• Defended convincingly in the live session, including “what would change your answer?”: +5

The Live Integration Session (60 minutes)

In front of a grader (or recorded, per your instructor):

1. Stand it up (~10 min) — on a clean checkout. Start backend, start front end, create something, reload, show it persisted. A build that only runs in your exact terminal is not done.
2. Walk the architecture (~15 min) — open architecture.docx, say the constraints and the justifications out loud. This is weighted most.
3. Defend the hard decision (~15 min) — if you attempted Hard tier, defend it with your measurements. Expect “what would change your answer?”
4. Show the agent log (~10 min) — one task the agent nailed, one it got wrong that you caught.
5. Reflect (~10 min) — what the right tool turned out to be; one thing you’d change.

The questions are not gotchas — they are a real design review: Why this database? What under concurrent writes? Where did the agent get this wrong? What did you measure? What would you change? If you did the architecture yourself, you have the answers.

Submission

Submit one URL via the course portal: a public GitHub repository. The grader will git clone it on a clean machine, follow your README to run it, and grade against the rubric. See Appendix A for the git workflow.

What the repo must contain

1. All source — backend, front end, schema/migration or seed script.

2. All Normal-tier deliverables (Medium and Hard add to them, never replace): architecture.docx, agent-log.txt, reflection.docx, and the header comment block.

3. A README.txt that lets a stranger run it from a clean clone. Template:

   # <Scope Name> — Capstone (Project 14)
   
   ## Stack
   <backend> + <database> + <front end> — justified in architecture.docx.
   
   ## Run it
   1. Install: <e.g., `pip install -r requirements.txt`  or  `npm install`>
   2. Initialize the database: <e.g., `python init_db.py`  — creates + seeds it>
   3. Start the backend: <e.g., `uvicorn main:app`  → http://localhost:8000>
   4. Serve the front end: <e.g., `python -m http.server 5500` in /web>  → http://localhost:5500
   5. Open the front end URL and create a record.
   
   ## Tier targeted
   Normal / Medium / Hard — see the header comment in <main file>.

4. A seed/migration step so the grader sees data without manual setup. Relative paths only — no /Users/you/... hard-coded anywhere.

Every deliverable is graded. A missing reflection.docx cannot be made up with more code. A missing architecture.docx is most of the grade gone. Budget for all of them.

Hints (Read Before You Begin)

• Write architecture.docx first. Before code. Non-negotiable. It is the most-graded artifact and it makes the build go fast. If you change your mind mid-build, update the doc — it is the source of truth.
• Build in layers, bottom-up: data layer → API → front end. Validate each seam (curl the endpoint before wiring the front end). Don’t build all three blind and pray they connect.
• Justify with constraints, not popularity. “SQLite because single-leader, dozens of rows, zero-config” passes the defense. “SQLite because it’s easy” does not.
• Scope down, not up. A clean, defended Normal beats a half-wired Medium. Reach for Medium/Hard only after Normal runs end to end on a clean checkout.
• Parameterize every query. The agent will sometimes regress this. Read every query it writes.
• Mind the seams — CORS especially. Decide same-origin vs CORS in the architecture doc, fix it once, and don’t rediscover it in front of the grader.
• Log the agent in real time. Five seconds per task now beats reconstructing a worthless log at the end. The grader can tell the difference.
• Take the keyboard when the agent wastes time. You are the senior. If a correction loop runs past two rounds, write it yourself and log that you did.

What Mastery Looks Like (Beyond the Rubric)

A great capstone has an architecture.docx a senior engineer would read without wincing — constraints named honestly, a stack chosen against them, and justifications that would survive a design review. The doc reads like a decision, not a description.

A great capstone has a stack choice that is defensible and matches the build. The student who wrote “SQLite, because single-leader and dozens of rows” and then built exactly that, and can name the constraint that would push them to Postgres, has the thesis. The student who reached for Postgres “to be safe” on a single-user app has missed it — over-engineering is its own architectural error, and the defense will surface it.

A great capstone has an agent-log.txt a senior could audit and respect. Scoped delegations. A real moment the agent was wrong and got caught. The log proves the human directed the work; it is the difference between an architect and a person who received a pile of plausible code.

A great capstone is the size it needs to be and not larger. Two resources where one would do is over-built; the rubric does not reward sprawl. Ship the minimum that is genuinely full-stack and genuinely yours.

A great capstone has the student’s name on it because the student architected the system. The agent wrote some modules. You decided which modules exist, chose the database, drew the seams, and can defend every one. That is what the live session is built to reveal, and it is the whole skill the three books were for.

A Theological Footnote

The frame across all three books has been one question: what does it mean to do this work well as a Christian? This week the question reaches its largest form — what can a Christian engineer build? — and the answer is the one Ephesians 2:10 gives: you are his workmanship, created in Christ Jesus for good works, which God prepared beforehand, that you should walk in them.

That is the doctrine of vocation, and it is the quiet thing this whole sequence was building toward. Your skill at building is itself a built thing — given to you, shaped by you through reps you chose to do, and meant to be used, in service to a neighbor, in the ordinary station God has placed you in. The capstone is not the Divine Service and it does not pretend to be. It is a small thing, built well and handed over. But a small thing built well, honestly attributing the labor of others — human and tool — without overclaiming and without falsely shrinking, is the shape of the good works the verse means. You don’t have to leave the keyboard to find your vocation. The keyboard, done faithfully, is one.

Colossians 3:23, the project epigraph, finishes the thought: whatever you do, work heartily, as for the Lord and not for men. The grade is for men. The work is for the Lord. Build it as if the second sentence were true — because it is — and the first will take care of itself.

Show up rested. Trust your training. Build something honest, and stand behind it.

This is the last project of the book. When it is shipped and defended, you are done with the course — and ready, finally, for the work the course was for.

Soli Deo gloria. See you on the other side.