All Workshops

Prototype Sprint

Working software you can demo to your board by the end of the week

Full day (6–8 hours)
Technical team (3–6 people)
On-site or remote
AWS-funded options available
Guarding the Flow in Production Environments, Input Guardrails, Query Rewriting, Retrieval, LLM, Output Guardrails
6–8h build session
6 technical team max
deployed prototype on AWS
1 week from concept to demo
Amazon Bedrock (Claude) AWS Lambda Amazon API Gateway Amazon OpenSearch AWS Step Functions Amazon DynamoDB Python Deployed to AWS

The problem this solves

Concepts convince nobody. Working software changes conversations.

When stakeholders can interact with an AI prototype that processes their actual data and produces a real output, the questions shift from “should we do this?” to “how fast can we scale it?” The Prototype Sprint exists to create that moment.

This is not a hackathon. It is a facilitated build session with a clear specification, the right infrastructure, and an experienced engineer driving. By end of day, you have deployed, running software.

Who this is for

CTO / Engineering Lead

You have an approved use case and a Concept Sprint spec. You need working code on AWS, deployed and demo-ready, by end of week, not end of quarter.

Technical Team (2–4 engineers)

You'll be building alongside an experienced AWS AI engineer. The session moves fast and produces real code your team inherits, understands, and can extend.

Product Owner / Delivery Manager

You need a live demo for the board meeting next week. The Prototype Sprint produces exactly that, working software on real data, with a documented handover package.

How it runs

01
Environment Setup
45 min
AWS account configuration, IAM roles, service provisioning, repository setup, and data access. Everything needed to start building immediately.
02
Core AI Pipeline
2–3 hours
Build the AI backbone: model invocation, prompt engineering, output parsing, error handling, and the core processing logic. This is the heart of the prototype.
03
Data Integration
1–2 hours
Connect the pipeline to real data: S3 uploads, API calls, database queries, or file ingestion. Test with actual documents, recordings, or data your team provided.
04
Interface Layer
1–2 hours
Build a front-end or API layer that makes the prototype demonstrable: a web UI, a Streamlit app, a REST endpoint, or a Teams/Slack integration.
05
Demo & Handover
45 min
Dry-run the demo. Document deployment steps. Walk through the implementation roadmap. Complete the AWS funding application if applicable.

The architecture you get

This is a representative production-ready prototype architecture for an AI assistant or document intelligence system, the pattern adapts to the specific use case but the structure is consistent:

User Interaction
Web UI (React / Streamlit)
Teams / Slack integration
REST API client
API Layer
Amazon API Gateway
AWS Lambda (routing)
Amazon Cognito (auth)
AI Processing
Amazon Bedrock (Claude 3.5)
AWS Step Functions
Amazon Textract / Transcribe
Storage & Memory
Amazon S3 (documents)
Amazon DynamoDB (state)
Amazon OpenSearch (vectors)
Output
Structured results
Audit logs (CloudWatch)
Export / downstream push

For multi-agent use cases, AWS Step Functions orchestrates agent workflows. For RAG (retrieval-augmented generation) systems, Amazon OpenSearch stores document embeddings. For real-time processing, Kinesis handles streaming data. The architecture is always AWS-native and designed to be extended to production without a full rebuild.

Prototype sprint vs. a hackathon

The Prototype Sprint is often compared to a hackathon. The difference matters.

Hackathon
No pre-defined spec, built on assumptions
Synthetic or sample data
Runs on a laptop, not deployed
Team picks up where it ended, cold start
No funding application, no roadmap
Prototype Sprint
Starts from a validated PoC specification
Uses your actual organizational data
Deployed to AWS, real infrastructure
Full handover: code, docs, deployment steps
AWS funding application + implementation roadmap

What “working prototype” actually means

A working prototype, as defined by this sprint, meets all of the following criteria:

  • Processes real data from your organization (not synthetic examples)
  • Returns accurate, structured outputs for at least the primary use case
  • Is deployed in a real AWS account, not running on a laptop
  • Can be demonstrated live by someone who was not involved in building it
  • Includes basic error handling and a documented deployment process

It is not a polished product, it will have rough edges and hardcoded assumptions. That is intentional. Its job is to prove the concept and unlock the next phase of investment, not to ship to customers.

From PowerPoint to Prototype, the complete journey from slide deck to deployed AWS application
From first conversation to deployed prototype in 3 weeks. The Prototype Sprint is the final sprint in that journey.

The roadmap to production

The implementation roadmap delivered at the end of the sprint maps the path from prototype to production.

Phase 1: Hardening (4–8 weeks)

Replace hardcoded values with configuration, add proper error handling, logging, and monitoring, set up a CI/CD pipeline, and complete a security review.

Phase 2: Scale testing (2–4 weeks)

Test with representative data volumes, tune model performance and latency, validate cost model at scale, and identify infrastructure optimizations.

Phase 3: Integration (4–12 weeks)

Connect to production data sources and downstream systems. Timeline depends heavily on the complexity of existing integrations and internal procurement processes.

Phase 4: Production launch

Staged rollout with observability tooling, monitoring dashboards, alerting, and a runbook. Organizations typically reach production pilot in 6–12 weeks post-sprint.

"The 3-workshop format gave us a working prototype in under a month. We went from vague AI ambitions to a funded PoC with a clear implementation plan. Exceptional facilitation."

Enterprise Client, Financial Services, Vienna

Prototype Sprint outcome: working demo, deployment documentation, implementation roadmap, AWS funding application pre-filled.

By the end of the day, the team has a prototype, a path to production, and a funded route to keep going.

Frequently asked questions

Does the Prototype Sprint require the Concept Sprint first?
The sprint requires a PoC specification as input, a clear definition of the use case, data sources, expected output, and AWS service selection. This is the natural output of a Concept Sprint. If your team already has an equivalent document, the Prototype Sprint can run standalone.
Who owns the code at the end?
You do. All code is written in your AWS account, committed to a repository you control, and handed over with full documentation. There are no ongoing licensing dependencies and no lock-in to specific tooling or vendors beyond the AWS services used.
What if the prototype doesn't work as expected on the day?
It's rare, but prototypes sometimes hit unexpected data quality or integration issues during the session. When that happens, the session pivots: we document exactly what blocked progress, what would be needed to unblock it, and what a revised prototype scope would look like. You always leave with actionable information, even if the prototype is not fully functional.
Can we run this as a remote session?
Yes. Remote Prototype Sprints work well for teams with strong engineering communication habits. The session uses shared screen, collaborative documentation, and a shared AWS environment. On-site sessions have slightly better energy for team-based builds, but the output quality is equivalent.

Prototype Sprint working session: technical team builds a demo-ready prototype on real data, on AWS, in the room.

The Prototype Sprint is the workshop where ‘we should try AI’ becomes ‘we have AI running’.