Skip to content
Page 6 of 7

Challenge 2: From Prototype to Product

Recap:

In Challenge 1, you built a prototype entirely by talking to an AI chat tool. It looked great: polished, interactive, with the features you designed. But the data was likely hardcoded, and the whole thing lived inside a chat window.

Then in Lesson 2, everything changed. You moved into a real development environment with an AI coding assistant that can read and edit your project's files. You migrated your prototype from chat into the project. It's real now, viewable in a browser, saved and synced. You learned that your code is just files, that version history means you can always undo, and that file access unlocks things chat never could: real data, multiple pages, targeted edits, and team collaboration.

You also did two things that set you up for right now:

  • You wrote user stories during the "Imagine the Upgrade" activity: features that weren't possible in chat but are now possible with file access. Those stories are your starting point.
  • You audited what's real vs. what's hardcoded in your prototype. That audit is your roadmap.

The Challenge

Turn your Federal Vendor Intelligence Tool from a prototype into a product. The big unlock: real data.

Your project's repository comes pre-seeded with real federal contracting data. Real vendor profiles from USAspending.gov showing Lockheed Martin, Boeing, RTX, Northrop Grumman, and seven other major contractors. Real award amounts, real agency breakdowns, real NAICS codes, and contract vehicle breakdowns showing how the government buys from each vendor (IDIQ, BPA, GSA Schedule, and other indefinite delivery vehicles). Your AI coding assistant should be able to find this data and figure out how to use it on its own. If it seems like it is having trouble, you can point it in the right direction: the data lives in the data/beginner/ directory.

The moment hardcoded text becomes real USAspending data is the moment this stops being a demo and starts being something acquisition professionals could actually use. With real data, you can start answering real acquisition questions: Which agencies has this vendor worked with? How do they receive their awards? What does their contracting footprint look like over time? That is what you are building toward.

As you go, keep building incrementally, one piece at a time, verified before you move on.

What to Build

Items are listed in priority order. If time is tight, focus on the items near the top first.

  • The tool displays real vendor data from pre-seeded USAspending files (or live API if your team connects), not hardcoded text
  • Award amounts are real: total transaction amounts, agency breakdowns, and NAICS codes from actual USAspending.gov records
  • The tool has multiple pages or sections with navigation between them (vendor profile, agency breakdown, NAICS analysis, whatever makes sense for your tool)
  • All changes are saved and synced: your work persists and your whole team can see it

These are options for teams that finish the baseline capabilities. Your team can also define your own stretch goals based on what interests you.

  • Add vendor search: let the user pick from the 11 pre-seeded vendors or type a name to filter the list
  • Display spending by agency: show a bar chart or ranked list of the top awarding agencies with dollar amounts, useful for assessing past performance concentration
  • Show NAICS code breakdown: what industries does this vendor operate in, with dollar amounts per code
  • Contract vehicle breakdown: show how the government buys from this vendor today (IDIQ, BPA, GSA Schedule, definitive contracts) using the awards-by-vehicle data, so an acquisition professional can see whether existing buying paths are available
  • Build a vendor comparison view: show two vendors side by side using data from recipient-details/
  • Add a spending trend chart: year-over-year award amounts from the time series data
  • Display subsidiary information: show the alternate_names array from USAspending (Lockheed Martin includes Sikorsky, Derco Aerospace, etc.)

A note about SAM.gov data

Your chat prototype may show SAM.gov information (registration status, exclusion records, solicitations) that was invented by AI. Before you try to make it real: SAM.gov has access restrictions and daily request limits that can block your progress fast.

Your project already has real SAM.gov data saved in the data/beginner/ directory. For this challenge, focus on connecting USAspending data first. If you need SAM.gov data, tell your AI assistant to use the files in that directory instead of trying to fetch it live. You'll work with SAM.gov data more in Challenge 3.

Tips

  • Start with the user stories you wrote during Lesson 2. You already planned this. Pick the one with the biggest impact and implement it first.
  • Use the "What's Real, What's Fake?" audit as your checklist. Each hardcoded item you replace with real data is a clear win. Tackle them one at a time.
  • Ask your AI coding assistant what data is available. Try something like: "What federal contracting data do we have in this project? Show me what's there and what I could use it for." Then follow up: "Show me an example of what the recipient detail data looks like for Lockheed Martin. What fields are there and what do the values mean?" The more you understand the data before building with it, the better your user stories will be. This is the Explore step of your workflow, applied to data, not just user needs.
  • Save and sync regularly. This is your safety net. If something breaks, you can always go back.

Go build. That is the brief. Spend the rest of this session block working on your challenge with your team. Your Facilitator will let you know when it is time for the Reflection.

Our recommendation: mob until you have clear swim lanes. Think of your project like a shared Google Doc. If two people write the same sentence in the same paragraph at the same time, their changes collide and one person's work gets overwritten. Code works the same way: when two people edit the same file at once, you get code collisions that lead to hard-to-trace bugs, lost work, or code that has to be thrown away. The safe way to split up is clear swim lanes, where each person works on a different section. Until your team has those swim lanes, mob: one person drives (hands on the keyboard), everyone else navigates (watches, thinks ahead, gives feedback). Rotate the driver every five minutes or so. One keyboard, zero collisions.