Kazuya

Posted on Dec 8

AWS re:Invent 2025 - Kiro meets SaaS: Generating multi-tenant agentic applications with a GenAI IDE

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Kiro meets SaaS: Generating multi-tenant agentic applications with a GenAI IDE

In this video, Aman and Anthony demonstrate building a production-ready multi-tenant SaaS platform with embedded AI agents in just two and a half weeks using Kiro, AWS's AI-powered IDE assistant. They showcase how Kiro's spec-driven development, agent hooks, and MCP server integration enabled them to create a complete control plane and help desk application following the SaaS Well-Architected Lens principles and leveraging the SaaS Builder Toolkit. The session includes detailed demos of crawling AWS documentation with Crawl4AI to create steering documents, configuring MCP servers for AWS services and Strands, and the actual development workflow that produced seven independently deployable components with 226 test files and 327 documentation files. They share practical lessons learned about testing frameworks, AgentCore integration challenges, and the importance of clear requirements, ultimately demonstrating how one developer achieved a 1:4 test-to-production code ratio without writing a single line of code manually.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Building Multi-Tenant SaaS with AI Agents

Good afternoon, everybody. My name is Aman. I'm a Cloud Architect at AWS. I work for Professional Services, and alongside me is Anthony, who's a Senior Solutions Architect at AWS. Together we'll be presenting to you SAS406, Kiro meets SaaS. Now this is listed as a 400-level talk track, so it's going to have a lot of video walkthroughs, but we do assume a level of SaaS knowledge as well as some AI tooling knowledge before.

But before we begin, I want to ask a question, and I want to see a show of hands. How many of you here have ever been in a meeting before where someone said, let's add an AI agent to it? Can I see a show of hands? Good, lots of people. That's great. And how many of you have been knee-deep building a feature when the business suddenly asks, oh, can you make it multi-tenant while you're at it, just very casually? Anyone who's heard that one before? Fewer people than the first one, that's all right.

For any of you who haven't been to either of these two meetings before, congratulations, you are in that meeting today. And what we're actually going to do is we're going to say yes, let's do it. And not only that, let's do it the right way: tenant isolated, well-architected, multi-tenancy in mind, the whole nine yards.

So as we begin, let's talk about what we actually committed to build. We committed to build a control plane on AWS, not a prototype, not a demo, the real deal: multi-tenant from the ground up, proper isolation, proper security, proper everything. We also committed to build a demo tenant application that is basically a service management product allowing tenants to create tickets, comment on them, or search knowledge bases. And what we wanted to do is bake AI agents into both of these applications: AI agents for the control plane allowing SaaS admins to manage tenant operations, and AI agents within the tenant app to allow tenants to actually communicate with the AI agent and raise tickets by natural language. And we decided to build all of this using the SaaS Builder Toolkit and the Well-Architected Framework, no shortcuts.

Now, if you're thinking that sounds like a six-month project with a massive team, well, that's what we thought too. But what if I was to tell you that there was a different way? And that's what brings us to our session today, and this is the roadmap. For the next 50 to 55 minutes, this is going to be your map for traversing this session. We're going to tell you this exactly the way we experienced this adventure. We talked about our goal, we're going to dive deeper into the SaaS challenges, and we're going to talk about the tools we used: Kiro, the Well-Architected Lens, and the SaaS Builder Toolkit. Then we'll go into the actual build, the adventure as we like to call it, the real story on how we actually built this thing, the wins, the way that actually works, as well as the lessons learned the hard way. And we'll wrap up with where we are today and what this means for building multi-tenant SaaS through AI. Sounds good. Let's jump in.

The Challenge: Balancing Speed and Quality in SaaS Architecture

So why is this quest so challenging? Because anybody building SaaS today is facing a fundamental dilemma. We're pushed to ship features and innovate faster than ever while managing complex architectures, and at the same time we have to manage tenant isolation, data partitioning, and the works. We need to handle multi-tenancy, ensure bulletproof security, and maintain a very high quality without accumulating crippling technical debt. Balancing this act of speed versus quality is the fundamental challenge we all face as builders today.

So let's jump into what we'll actually be building. On the left-hand side, you can see the control plane. We're going to start with the necessary control plane elements. We're going to need an entry point into our application. For us, that's going to be the SaaS admin portal. It's going to be a React application hosted in an S3 bucket fronted through CloudFront. The backend services are going to be behind an API authorizer using API Gateway, and that's going to be connected to an identity provider such as Amazon Cognito. The backend will also host services for tenant registration, deregistration, user management, as well as all other SaaS operations.

Next, we'll need to embed some AI agents into it. So what we're going to do is we're going to create a Lambda proxy, and then we're going to use the Amazon Bedrock Agent Core runtime

combined with Amazon Agent Core short-term memory for session level persistence. All of the images are going to go into our trusted ECR repository. That's all great. All of this can actually take a lot of tenant registration and user registration requests, but how do we actually provision for that? We need a provisioning engine. What we're going to do is connect our APIs through an event bus and connect our service to be a step function that can actually trigger a code build job and run some CDK code to actually provision the tenant infrastructure. That is the snapshot of our control plane services for tenant registration, deregistration, user management, and AI agent baked in, connected through an event bus to a provisioning or a deprovisioning service.

Next we need to think about our tenant application. For this demo, we wanted to build a service management product. We decided to use serverless tech to actually power up the features for the demo, and we also added an AI agent to it. Similar to the control plane, we have a Lambda proxy that fronts the agent core runtime with agent core short-term memory, and we make sure that we have end to end observability through agent core observability. And finally, that is our quest for today. You can see that the left side covers all the services that we need for the control plane, and the right side will serve as our tenant application plane.

Kiro's Core Capabilities: Spec-Driven Development and Automated Workflows

So how do we actually tackle all of this without a massive team and a six month timeline? Well, that's where Kiro comes in. Here's the thing, building a to do app with AI, lots of tools can do that. But building a secure multi-tenant SaaS platform with AI agents embedded with proper isolation and well architected principles, that's a very different game. Before we go into SaaS, let's dive into the capabilities of Kiro first. For those who haven't used Kiro, this is going to be a somewhat 200 to 400 level talk track, so we'll take you along with the journey.

First, spec driven development. You describe what you want to build. Kiro generates a comprehensive spec with requirements and architecture. You iterate together until it's right, and then you build from that approved blueprint. It's like having a tiny obsessive project manager in your IDE. Everything's documented, everything's very well structured. The tasks have links back to the requirements, and nothing falls through the cracks. For the first time after using Kiro, I felt like it was an actual AI partner instead of a black box because I could see what it could see.

Second, agent hooks, automated workflows that can run in the background. Save code, tests get generated. Update components, documentation gets updated. Change some infrastructure and security tests run. Quality becomes automatic. And third, Kiro allows you to connect to all the MCP servers on the internet. What that allows you to do is actually expand Kiro's context and teach it things that it doesn't really know about. Spec driven planning, deep context, and automated quality, that's what makes Kiro so powerful.

Live Demo: Exploring Kiro's Features from Steering Documents to Agent Hooks

So next we're going to jump into a demo. I'm going to move to the lectern to demo this to you. Let's begin with the capability overview. The ghost icon on the left provides a comprehensive menu of all Kiro features. As you can see, this includes specs, it includes hooks, and it also includes steering documents, and an advanced context management plan for MCP servers. We currently have the FetchMCP server enabled, which allows Kiro to access any website on the internet and learn from it.

The next feature that we're going to explore is agent steering. We're going to start with generating some steering docs. Now this is a brownfield project. When I click that button, Kiro starts reverse engineering the project's source code to create detailed markdown files. These documents provide essential context for specs and prompts that you'll be running for the entire project. With a single click, Kiro has automatically generated these files, and for this demo, what we're going to be using is a project that's based on HTML, Python, and SQLite database.

The first file that Kiro generated is a product.markdown file. This document provides a clear human readable narrative of the source code functionality, and as a developer, I can review this file to quickly grasp the application's purpose. The next important document is the tech.md file.

This document summarizes all the technical components within the source code. It details the libraries, specific versions, and packages used both for the data layer, as well as some important commands that you need to run your project. The final document that Kiro will create from the steering docs functionality is the structure.md file. This file acts as a roadmap for the AI, enabling it to understand the source code structure. When I request a new feature specification, Kiro keeps to the original project's structure and follows the conventions because of this file and what's in this file.

Users can also create custom steering files. Users can create custom steering files to enhance Kiro's functionality. It can be done manually by creating a new file and fiddling with it yourself, or you can ask Kiro to create one for you. In this case, I'm creating a style guide that's based on PEP 8, which is a very well-known standard for Python code. Now the next thing Kiro's going to do once I give it this prompt is it's going to use the Fetch MCP server to actually retrieve the information that it needs for this PEP 8 style guide. And then it'll ask me for approval before every external call.

It'll then summarize this document and save it as a new style guide.md. As you can see, the steering file has detailed understanding of the PEP 8 standard for Python, and it'll be included now for every prompt that you give to Kiro in this project. In the chat interface, developers can seamlessly switch between Spec for structured development and Vibe for more freeform interaction. For our spec-driven workflow, we'll start with a simple prompt to add a new feature to manage categories in this project. From that, Kiro will build out detailed requirements, a design document, and a project plan that it can iterate on and you can iterate on with Kiro before writing any single line of code.

To accomplish this, Kiro ingests the steering documents that we created earlier. This includes the product document, the structure document, and the tech document, as well as the custom style guide we created earlier. It analyzes the source code and then begins generating the first part of the spec. This first part is called the requirements.md file, and it expands our initial prompt into a fully realized feature concept. It utilizes the EARS format that stands for Easy Approach to Requirements Syntax. It's an industry standard, and you may have seen this before, as there's going to be a clear acceptance criteria for each requirement.

Once the requirements are set and we're happy with them, we move on to the design phase. Kiro translates the requirements into a technical implementation plan or a design.md file. This requires deep understanding of the existing source code, and this is the file that I spend most of my time in. This file is very well suited to architects as it will outline the architecture of what it's about to build, as well as what is the plan for building it with some given examples. You can see it'll have things like what does the data model look like for this category feature, as well as what the error handling techniques are going to be and all of the good stuff.

Once we have our design approved, we move on to our final step. And this final step breaks down the requirements and the design document into comprehensive project tasks that Kiro can execute and keep track of. Each task includes sub-elements, a status tracker, and a clear linkage back to the specific requirement that it fulfills. What this does is what I said that the obsessive project manager does in your project. You can actually see all the tasks, and it marks them as complete as it goes through them.

Now let's conclude with a look at our final key feature, agent hooks. Hooks can easily be configured from the Kiro panel using a very simple form, and you can describe in natural language what you want the hook to do. In this example, I'm going to ask Kiro to monitor for any changes in any Python or HTML files, and when that file is saved, I want it to summarize the changes and append them to another file called changelog.md.

What I want to do is have a tracking system to be able to log all my changes. From this natural language, Kiro generates the hook. The hook consists of a few key elements: an expanded, more detailed prompt, the trigger event, which in this case is on file save, and some file patterns to monitor, which in our case are going to be .py or HTML. This hook is actually placed into the .kiro folder within the IDE. It also includes a title, a description, and an easy toggle to turn it off and on. This is how you automate your workflows within Kiro.

New Kiro Releases: Property-Based Testing, CLI, and Kiro Powers

Kiro is amazing, but it's still growing. There are some new releases that do deserve an honorable mention, and I'd like to share those releases with you. First, property-based testing. Traditional unit tests check for individual examples. Given this input, do I get this output? It's heavily biased by the developer developing the feature, and a developer can easily miss some edge test cases. Property-based testing is different. What it does is it works out what are the properties of a spec that must hold true at all times. Then it uses a generator to generate hundreds and thousands of tests and runs through them. It makes systems more robust because even if one single test case fails, Kiro has found a bug. It needs to then ask you whether you'd like to change the source code or the spec.

Second, Kiro CLI. Kiro CLI extends your AI agents from the IDE into the terminal using the same configuration and capabilities. Debug production issues, scaffold some infrastructure, or automate workflows without context switching. AI assistance where you actually need it. This is actually a facelift on the old Q developer CLI and now fully integrated into the Kiro CLI.

Third, when building complex systems, your code often spans multiple repositories. For SaaS, it's especially true. You're going to have a front-end repository, back-end repositories, specific libraries, infrastructure code. Kiro allows you to open all of these repositories within the Kiro workspace while allowing you support for multiple roots. That means that there's going to be a .kiro in each of these projects, and Kiro knows where you are contextually.

And finally, checkpoints. This has been a lifesaver. As a developer, I tend to frequently go off the rails and get too knee-deep into a feature in a particular session, and it is an auto-save checkpoint that I can revert back to within a session. And this one is actually hot off the press. True story, I put this slide together yesterday, so I wanted to share this with you.

Kiro Powers is the newest addition to Kiro's capabilities. Even though we're not using this in the context of the presentation, we'll talk about it a little bit. Think of a power like Neo in The Matrix. What if you could download Kung Fu right away and use it and forget about it once you're done with it? That's what Kiro Powers is all about. When you load a bunch of MCP servers into memory, that takes up a lot of context from your sessions, but Kiro Powers makes this dynamic. When you say things like I want to work on the database, that database command would trigger a power that you might have installed. In this case it could be Supabase, and it will help you talk to that database with the MCP servers required. And once you say I want to deploy something or create a new agent using Strands, it will take and download the Strands power, and you'll have all the access to the steering files as well as the tools for Strands.

You can browse all available powers on kiro.dev/powers. We already have a wide range of powers listed, allowing for API testing with Postman, design to code for Figma. Supabase also is available to power up the Supabase databases, and there's a new SaaS Power that I was tinkering with last night which seems super promising. We haven't used this for this demo, but you should sure go and play with it.

Here's how you see the powers option once you update your Kiro. You'll see a tiny ghost icon with Zeus's Thunder showing off its powers. I absolutely love this little ghost. You simply can one-click install any power and start using it today. Cool, we've shown you some of Kiro's capabilities. Powerful stuff.

Adding Wisdom: Integrating the SaaS Well-Architected Lens

But let's be honest, the risk with AI isn't that it cannot build stuff. The risk is that it will happily build the wrong thing really, really fast and really, really well. And in multi-tenant SaaS, wrong is expensive. A tenant isolation bug, that's not a quick hot fix, it's a security incident. It's customer trust and potentially your business's reputation. So we needed to give Kiro a little bit more than just technical capabilities.

We needed to give it wisdom, the accumulated knowledge of what makes SaaS architecture work in production. And for us we needed a North Star for that, and we chose the SaaS Well-Architected Lens.

The SaaS Lens addresses unique challenges of multi-tenancy and gives you a common language for architectural decisions. And here's how it shaped our actual requirements. Operational excellence meant tenant-aware monitoring. We needed to understand the health and performance of each tenant and not just systemwide. Security being non-negotiable, the lens enforces that tenant isolation is absolute foundation. Any breach is catastrophic, and our design had to be bulletproof from day one.

Reliability meant blast radius containment. Preventing one tenant's issues from affecting others is super important. Nobody wants to be woken up at 2 AM because of a noisy neighbor. Performance efficiency guided us to implement tenant-based scaling, which is far more cost effective than one size fits all. And finally, cost optimization. We need to ensure that we're protecting the business's bottom line as we scale, and this part of the pillar helps us with that.

Web Crawling and MCP Integration: Teaching Kiro Best Practices

Now the next challenge that we faced is that we needed to somehow get all of this in Kiro's context. Now, the SaaS Lens is actually a collection of web pages on the internet, and that's where we figured we need a crawler. To do this, we'll use an open source web crawler with over 55,000 stars. Crawl4AI is my tool of choice for open source web crawlers, and I use this all the time when I'm web crawling.

Why do I like it so much? First, because it's markdown native. It'll scrape and process all the documents into a markdown file, which is great for LLMs because LLMs love markdown. Second, it's fast and efficient and asynchronous. I can actually crawl multiple links together at the same time and extract media tags such as images, audio and video. It also handles the tricky stuff for you, such as infinite scrolls or some other JavaScript magic that is new on the block. And finally, my favorite, it's free and open source, so you can use it too.

So next what we're going to do is we'll start in Vibe mode and ask Kiro to use Crawl4AI to crawl the SaaS Well Architected Lens. We've given it the URL and right now what it's trying to do is it's trying to install Python and pip dependencies and Crawl4AI to my laptop using its agentic features. Then it uses this understanding of the library to write a Python script that will help me crawl the entire SaaS Well-Architected Lens. It quickly figures out that it needs to fetch the supporting links and not just the landing page. It goes back and forth to ensure the completeness of the crawl.

Next, we need to optimize the relevant content and convert it into a steering document. After the crawl is complete, Kiro automatically cleans the data, removing irrelevant texts such as cookie preferences to ensure the content is usable. After a few iterations, we have our final steering document. This gives Kiro our first superpower that we needed, the wisdom that we were after. It lets us stand on the shoulder of giants and lets us build from that instead of making the same mistakes again.

Now you can see the finished version of the crawled and optimized SaaS Well-Architected Lens as a steering document within Kiro. Next, what we want to do is arm our IDE with some important tools. What we're gonna do is we're gonna edit the MCP.json file, which is where all the MCP config lives. We're gonna attach the Strands MCP server, which has specific information on how to use Strands to build agents. We're gonna also add the AWS documentation server that provides our IDE up-to-date information on AWS docs. And finally, we're gonna add the Amazon Bedrock AgentCore MCP server because this is a new service and to get around the context limitations for foundational models we've got to do that.

And to complement this, I'll also give Kiro a prompt. I'll ask it to create a steering document that prioritizes the use of these MCP servers whenever it's not sure. This helps Kiro to not hallucinate details, and it'll now go and look up the MCP server to expand its context whenever it's unsure. As you can see, Kiro is now reading all the steering documents.

It's also reading up the MCP.json file to understand all the MCP servers, and finally, it creates the actual steering document for having an MCP-first approach. This is the actual steering document that Kiro generated from that prompt, and this tells Kiro every time that it's trying to do something to go look up the MCP servers first to make sure that your code is high quality and is following the best practices. Cool, we understood how to give Kiro a North Star through a steering document.

The SaaS Builder Toolkit: Accelerating Multi-Tenant Development

Next, what we wanted to do is actually do something else. Knowing the principles is one thing, but knowing the principles doesn't mean that you've got to rebuild the same stuff over and over again. For this we needed an accelerator. For that we used the SaaS Builder Toolkit. SaaS Builder Toolkit is an open source infrastructure tooling from AWS that solves the common problems with every multi-tenant SaaS. Tenant onboarding, user management, isolation, metering, that stuff's all built into the toolkit. So instead of building all of that again, what we want to do is we want to build on top of all of that.

And this is what the SaaS Builder Toolkit architecture looks like. The control plane handles all the SaaS management operations such as tenant onboarding, user management, billing, and the works. You can interact to it through a CLI or an admin webpage. The application plane is your actual application code, and here's what's important. SBT is completely unopinionated about what you build. Any application code works as long as you can subscribe to the relevant control plane messages and keep to the necessary contracts.

These SBT utilities accelerate common tasks such as tenant provisioning, deprovisioning, user management, and more is coming as the toolkit evolves. In the core utils is where you add your application specific configuration. Tenant provisioning logic goes here, identity settings go here, authorization rules go here. And tying it all together is Amazon EventBridge. This is the event bus which takes the messages from the control plane to the application plane and the application plane to the control plane. It includes necessary helpers that makes it easy to publish and subscribe to these messages.

Now this architecture is powerful, but it's also complex. So the question now becomes, how do we give Kiro deep enough context to understand SBT? Now as we need to finally teach Kiro about SBT, I'd like to repeat these are prefabricated components. You can look at them as L3 constructs, which are basically a collection of AWS services that are used to build out control plane services.

To do this, what we're going to do is we're going to use another open source tool. We're going to use GitMCP this time. This is a tool that allows you to convert any Git repository on the internet into an MCP server. We're going to generate a URL from GitMCP. Then in Kiro, we're going to ask Kiro to go and add this URL by first understanding it and then attach it to the MCP.json.

Kiro will go and fetch the information about this MCP link that we've just provided, and it's going to use its fetch ability to understand the link. Then it'll go and update the MCP configuration file and the steering documents that we created earlier by reading them first into the context and then adding them into the context. It's also going to ask you every time it's trying to perform a particular operation. You can also go ahead and trust them if you don't want Kiro to constantly pester you for permissions.

And the final result is that SBT.AWS is a new MCP server here, which is powered through the GitMCP connection that we made, and the MCP steering document also has the required updates about the SaaS Builder Toolkit. Now Kiro knows about the Well-Architected principles as well as has an MCP server that can read up the SBT documentation.

Secret MCP Sauce: Essential Servers for AWS and Development Workflows

Cool. Now that we're here, it almost feels unfair to not share with you wonderful folk this secret MCP sauce that I use all the time. Feel free to take a click in the end and I'm going to be really fast with these. You can attach the AWS Knowledge MCP server if you're looking for AWS best practices, information from blogs, white papers, and having your IDE have this information. You can use the AWS Lab CDK server if your preferred tool of choice is CDK and you do not want any hallucinations in your code.

And also it gives you deep enough context about CDK and AWS, allowing you to write more robust CDK code. If you're tired of hallucinated Terraform resource names, the Terraform MCP server is your friend. These are all servers available in AWS Labs, and there's also going to be a resources section in the end with some links.

This is a bit of a secret. The AWS API MCP server is what you can use to give Kiro some superpowers to run CLI commands in the background and go and query your AWS account about everything that's deployed in there. You can use this to search logs, list S3 buckets, and whatever you want to do. Context 7. If you're a developer like me and you love to build on Next.js, NestJS, FastAPI, FastMCP, but you're tired of IDE agents constantly using an old version or hallucinated details, attach Context 7 and you'll get access to up-to-date information.

Chrome Dev Tools? Well, this gives Kiro another superpower. It can open headless browsers and go and traverse and check what it's actually built for you. I also use it all the time to book really cheap flight tickets, by way. And finally, the GitHub MCP server. No developer likes to actually fix any conflicts, and this is where the GitHub MCP server is your friend. You can actually tell it what you want to really do, and it will work through all the complex Git commands under the hood, sometimes that otherwise would take you hours to go look through Stack Overflow to find, and it does them for you.

Anthony's Build Journey: From Planning to Implementation

So that concludes the first chapter of our story, setting the foundation. We've established our principles, gathered our tools, and charted our course. But planning the expedition is one thing, and actually climbing the mountain is another. And to be your guide for that climb, I'd like to share the hands-on story of what it was like to build this. I'd like to invite Anthony, my co-presenter. Thank you. Thank you, Aman, and hello everybody. Good to see you here today.

So with all that foundational context and tooling in place at this point, the first task when we're going to be creating a new project, so not starting from brownfield in this case, we're starting from a greenfield, is to begin working directly with Kiro from its very basics and from the spec-driven development perspective. Now it's important to understand that we're not going to be able to just simply use easy simple prompts, asking a prompt and getting a response back. For a project of this complexity, we need to first set out the guidelines of what the overall project happens to be, utilize and have a conversation with Kiro to basically create a collaborative planning session between me as the developer and Kiro as my AI assistant.

By doing this process, I outlined to Kiro the vision for this complex multi-component SaaS application. And Kiro responded back to me first with a project plan, which is in itself a spec document with requirements, the design, and the tasks. But those tasks were then executed to actually create ultimately a breakdown of the solution itself, and ultimately to seven distinct independently deployable components that included the SBT infrastructure that Aman went over with you, as well as the details for the AI help desk that we wanted to create on the application plane, and all of the services such as tenant onboarding.

This meta-level planning was absolutely critical for the project of a scale and of the complexity of this one. It allowed me to visualize the architecture with Kiro and to identify the integration points well before we actually started any coding itself. This upfront AI-assisted planning saved me an immense amount of time as we went down the process and certainly extra rework.

But a plan is more than just a list of components. Also, as a part of this planning process, Kiro was able to generate documents such as this detailed architectural diagram. This also gave me an immediate visual blueprint of what the entirety of the system was that I was about to build together. I want to point out a few key architectural decisions that we solidified during this stage. You can see the clear separation between the tenant management agent for our SaaS admins and the help desk agent for our tenants. We also explicitly defined the need for a tenant context layer.

The tenant context layer included a data isolation enforcer. This was a direct result, by the way, of Kiro looking at, reading through, and understanding the Well-Architected SaaS Lens as it realized that tenant isolation in the case of a SaaS application was a non-negotiable requirement that it needed to include. Also at the bottom, you can see that we also leveraged shared AI models through Amazon Bedrock throughout the application, and having ultimately this total visual blueprint ensured that I, along with those that were looking at this with me, were aligned together with Kiro and ultimately what we were going to build.

So with the solid plan and this clear architecture outlined for us at this point, with the requirements documents ready for us to start implementing, the next step in this journey, of course, was the actual day-to-day realities of development with this coding assistant and ultimately as well the lessons that I learned and how I had to evolve in certain cases as those changes came about. As I moved from blueprint to implementation, the focus also shifted to ensuring the quality and consistency at scale for the solution that was being built. This became a story of continuous learning and adaptation for both myself as well as my AI partner.

We're going to walk through ultimately how agent hooks were used to enforce version control, how we enhanced our requirements ultimately with more specific details as time went on or we discovered that there may be missing holes, and most importantly, how we navigated the challenges around testing to forge a robust automated testing strategy with the project. It's important to note that this is where the human-in-the-loop philosophy really was put to the test and showed its importance.

So let's dive in first to the day-to-day development process with Kiro. First, we would start out by reviewing our specification documents. By thoroughly reviewing these with Kiro, we can see how that particular specification is outlined. We understand what the design and the requirements and the tasks are going to be before we execute them. We can also continue to refine this with Kiro at this stage as well if we need to add any additional requirements for that particular component.

Next, we're going to start engaging with Kiro to have it run through the tasks in the task part of the requirements one step at a time. This iterative approach allows us to focus on the specific components that we're working with at that point and to ensure that each piece of the solution was built to the highest levels of standards. Kiro, of course, plays a crucial role here as well as it is then generating the code and providing the guidance as I work through each one of the tasks.

Next, we need to review the results as Kiro is creating it. After completing each individual task, I went through and reviewed what Kiro had created, making sure that we're matching up to both the design and the requirements specified previously. This step included going through and doing code reviews, running through unit tests and other testing, and getting feedback to Kiro as well as hearing feedback from Kiro based on what I'm finding. Kiro's insights here also help to identify any potential issues and ultimately improve the final code quality.

Next, as a part of that process, we do and run these build and unit tests. Testing, of course, should be a critical part of the success of any project, especially one of this complexity. Kiro built and ran those tests to verify that each component functioned as we expected. It helped to create the unit tests as well as ultimately functional tests and served a really good purpose in creating a broad set of test coverage for the project, as we'll see here in a moment.

Of course, issues are going to arise, and as they do so, especially during the testing process, we need to take care of those, so I worked with Kiro to collaboratively work through those issues. Once all of that was completed, we were then ready to go ahead and jump forward and start working on the next specification and its tasks. This iterative process continued until we had gone through all of the requirements and all of the tasks involved and the final SaaS solution was built.

The Results: A Production-Ready SaaS Solution Built in Two and a Half Weeks

One of the things that I implemented as a part of this process is that at certain milestones, I also worked with Kiro to have it generate CLI tools for me to create deployment scripts into my AWS account so that I could actually test the end results in a real world environment as it went along. So ultimately, what did we get out of this? Well, we have of course all of the code and the interactions that I had with Kiro, which we're going to look at here in a moment, and then we actually have the running version of the application which we'll see as well.

So let's start first of all with what Kiro created for us. What we see here as we begin is my Kiro IDE. Up on the upper left we see the specification documents, then the agent hooks, again the steering documents that I've worked with, and finally the MCP servers. One thing to note here is that there are quite a few more specification documents than the original seven that were created as part of the project plan, which you can actually see in that project plan requirements document here. That goes to show that over time and as I learned more and needed to add maybe additional requirements, Kiro was flexible enough to work with this.

As we scroll through here, the requirements, we can then move over to the task list. One of the things that I want to note on the tasks is that you can actually add additional information into the task document that acts as a sort of steering mechanism specifically for that requirements document and those tasks that you're running. Whereas the main steering documents themselves are global to the entire project, this gives you a little bit more flexibility on a requirements by requirements basis. So here we can see now opening another one of those. Now this is the requirements document for the SaaS admin dashboard, just showing another example and its tasks as well.

Now we did have two agent hooks that I put in place. The first one here that's getting opened up was for the creation of documentation. I asked Kiro to create documents as it went along and to thoroughly document not only what it's doing, but also information that would be valuable to other developers in the long run. And the second hook here is a hook that I created to have Kiro work with Git automatically for me so that every time it finished a task, it would commit that into Git so I never accidentally lost anything without it being under source control.

And the agent steering documents, this also continued to grow over time as I learned more and more throughout the project. One thing that came up during testing, for instance, is that I needed Kiro to make sure that it was actually doing a build of the TypeScript before it actually ran the test, and occasionally it would not do that for me. So I just simply asked Kiro to create a steering document to provide that capability. Now since this was done very early in the days of Kiro, Kiro has of course increased in its capability and it now has a lot of this testing for TypeScript capability right inside of it that can be fixed, but at this point in time it was certainly something I needed.

Next, if we flip over to the file side, we can see the documents that were created again under the Kiro directory, similar to what Aman showed earlier, including the specification documents, the steering documents, and any agent hooks that have been created. Down below that we can see the actual source code itself in this packages directory. Now this overall directory structure for the project, Kiro and I worked on together to create, and this is a mono repo with all seven of these components built into the same repository. Again, if we had the newer capabilities of Kiro, we might have instead broken this out into different repositories and it could have worked with all of those together today, but in this case, the mono repository worked very well.

So we've seen at this point what it is that Kiro can output. We've seen how we can interact with it. And as we're looking at this final product and what it's produced, it's actually pretty impressive. I'd like to show, before we jump into the demo of how the UI actually works and that this is actually a true product, it's a true solution that we made and it's not smoke and mirrors, I do want to go over some pretty impressive numbers with you. First of all, as I mentioned, this is a mono repo. It has seven packages that were built within it. This allowed us of course to maintain consistency across all of those different packages and solutions, although they are all independently deployable, which is one of the requirements that I asked Kiro to do.

Also, as a part of this repository, testing again was very important. Kiro created 226 different test files for this project. The project itself was many tens of thousands of lines of code, and I wanted to ensure that we had really valid and thorough testing for the solution. What we ended up here in a code or a test to production code ratio was one line of test code for every four lines of production code. Now, I've done a lot of development in my days, but I do have to say by working through this project with Kiro, I definitely had the most thorough testing from a unit test and functionality and component test scenario that I've probably ever had in any other project. It is very thorough.

The other part again is that Kiro also created documentation, and again not just documentation about what it's doing, but also it created API references. It created user guides for both the tenant admins as well as the help desk, and it created, of course, technical specifications that could be important for developers who come along after me and want to maintain or work on this project into the future. So 327 documents ultimately were created as a part of that. Of course, we did deploy into AWS, into an AWS account. So for each component I had an individual CloudFormation stack that again Kiro created for me on my behalf and even when I asked it to would deploy into AWS.

Now all of this is pretty impressive, but the most impressive thing out of all of this is that this entire solution, including a full-fledged production-ready SaaS, a full tenant application that is a help desk essentially with ticket creation, all of the data interactions thereof, as well as thoroughly defined security including full tenant isolation, was created by one person in two and a half weeks. Beyond that as well, I never wrote a single line of code in order to do this. Kiro did it all for me. Was it always perfect? No, I had to work with Kiro and make sure and address things as they came up, but overall I was incredibly impressed in this capability where essentially if we're creating features, we can take what took weeks down to days or even months to weeks, and it's a very impressive capability and I was quite impressed with it I should say as I was working through it.

So let's take a look at what this actually looks like from a UX perspective. What we're starting out here with is the admin screen for the SaaS side of this, for SaaS admins I should say. So specifically looking at how you would interact with the control plane from SaaS. So we have a SaaS admin here. The SaaS admin is going to authenticate, and I am using Cognito as a part of this project to act as an IDP.

Here we see the dashboard that is presented for this user. Now this user is an admin, so they have more capabilities than other users would have, including a full dashboard support, the ability to introspect and find tenants, to edit those tenants, to create new tenants. Now one thing I will say about this dashboard that's pretty interesting, and I'll be honest, a lot of this actually isn't hooked up to anything. It's a little smoke and mirrors on some of these dashboard features. But Kiro created all of that automatically. I didn't ask it to do that.

It's giving suggestions on what a successful SaaS solution and the documents that it would have within it. Here we can see one of those tenants that I created, as well again as the ability to create new ones. We also have a user management section here, and we can see the tenant admin for the tenant that I created as well as the administrative admin. Now if we were doing this maybe in a different way, I wouldn't necessarily mix these two user bases together, but it demonstrates the capability and again all of this is hooked into Cognito.

But we also had one extra requirement, and that was that we wanted to have a full AI assistant and an agent that could interact with the same APIs that we were creating for managing these tenants, doing onboarding, all of that. So we created that agent here with tooling to access those APIs and the communication protocols to go back and forth with it. So I can ask about tenants,

I could ask for information about a particular tenant. I could even ask the AI agent to create a new tenant or onboard a new tenant for me. And again, all of this was a part of that initial two weeks. Now here we see the opposite side. This is from the tenant's perspective. So this is the actual help desk interface that was created. We can see that user that was part of the tenant admin user that we saw earlier. And again, when I sign in, it's going to authenticate against Kiro, and we have a completely new and different interface.

Now Kiro, kind of out of the box when it's creating UX, likes to design things very similarly, so we have a left nav here and a dashboard. This dashboard actually is quite a bit more functional than the one that we saw inside of the admin, by the way. It's more hooked up, but as an individual user of this tenant, I can go in, I can see the help desk tickets that were created for the user. I can manage those tickets. I can submit and create a new ticket, as you can see on the screen here, and of course, ultimately, we can then put comments on those tickets, anything that you would expect from a help desk.

And we did add another agent here to interact with the help desk as well in a very similar manner to what we saw with the tenant administration. However, in this case you could ask for information about a ticket. You could create new tickets. If you were dealing with a knowledge base, for instance, we now have the structure in place that we could hook that agent up to a knowledge base and have that implemented as well as part of the ticketing solution. Pretty powerful.

Here we can see the CloudFormation stacks. Now I mentioned that there were seven that were a part of this project, although there are nine listed here. That's because there were a couple that were already in my account at the time, but they are fully deployed. We're jumping over now into DynamoDB and we can see here the many tables that were created as a part of both the help desk application as well as the SaaS solution itself, and again all of this was created by Kiro, right? I never wrote a line of code in order to make any of this happen.

If we take a look at and explore one of the tables here, we're going to open up the help desk ticketing and we can see those two tickets that we saw in the help desk application are listed here too. And notice that the tenant ID is in this case the key for this table to ensure that we're properly applying, I should say, tenant isolation at the data level since this is a pooled SaaS solution. Here we can see the Lambda functions that were created for this. There are 47 of them, and this covers all of the CRUD interface between the creation and updating of the various different data types that we have in the solution. And finally, if we jump into Amazon Bedrock Agent just to show again that we're not dealing with smoke and mirrors here, we can jump into agent runtime and we can see our two agents listed, both the tenant agent as well as the help desk agent.

Lessons Learned: Challenges, Adaptations, and Key Takeaways

All right, so pretty powerful stuff and pretty amazing what you can accomplish in two weeks with one person. Oh, and one other thing, most of this time, by the way, was Kiro just running in the background because I have a day job as well, right? So it was doing most of this in the background while I was doing other things. But it was not all sunshine and roses, and with any project you're going to have issues that are going to come up. There are going to be trials and tribulations that you must encounter along the way, and it certainly was the case here too.

These challenges pushed me to, in some cases, even pushed my resolve into wondering what I had gotten myself into, but ultimately I was able to adapt and ultimately made me stronger and learn more about how Kiro works. Today I want to share some of these trials that I had so that maybe you can learn from what I had to go through and possibly not have those same issues as you work through them as well. It also really kind of solidifies again though, that although Kiro can do so much on its own here, there still must be a human in the loop to validate and verify what's going on and to address challenges as they appear.

So as I navigated the development process, here's some of the challenges that I had to work through and really pushed me to adapt. First, testing and debugging issues. When I first started the project I did make sure that as part of the requirements that I wanted to have testing as a part of the solution. However, Kiro, if you're not super specific, and this goes for pretty much any AI-assisted development I should say, or vibe coding even, can sometimes go off on its own and do its own things from one session to another. So I would end up in certain cases with two completely different test frameworks that were implemented at the same time. Now I could have

fixed that from the very beginning and made sure that didn't happen, either by implementing the appropriate steering documents to drive Kiro to use one centralized testing framework or even have that explicitly in the requirements. But I didn't have it from the beginning, so those are things that I had to work through. As you're beginning to go through the process and really working in spec-driven development, my suggestion to you is to make sure that you take the time at the beginning to really analyze and understand what's inside of those requirements and help Kiro to build to what your vision is by being very explicit within them, and you wouldn't necessarily run into this particular issue.

The second one that I ran into was around AgentCore and Strands, and specifically because when I first started doing this project, again it was in the very early days of Kiro, but also the very early days of AgentCore and Strands. In one conversation that I had with Kiro, it actually told me that AgentCore didn't even exist because it had no idea that it did, so I had to go an extra step in this case and actually teach Kiro about AgentCore and about Strands by using some of the techniques that Aman talked about earlier. Having those techniques in my back pocket really saved me in that case because I was able to simply show Kiro here's how you actually implement these solutions. In my case, there was a very early getting started AgentCore capability that's still out there, by the way, and since it was on GitHub, I used GitMCP to create that MCP link and Kiro learned everything that it needed to from there. So pretty powerful way to get around it ultimately, but it was certainly a challenge to overcome.

And lastly, I'll just reiterate again missing requirements. This also came up as I was beginning to work inside of the help desk part of the solution. I had focused so much of my time and effort and energy into the creation of the SaaS solution and making sure that that SaaS solution was production ready and all the security was following the best practices from the Well-Architected Lens and following along with the best practices from the SaaS Builder Toolkit that I neglected some of the requirements that I really needed inside of the help desk application. So again, I had to go back, opened up Kiro to a new session, made sure that I was in the spec side of the house, and just simply started working with Kiro and added new specifications in order to pick up that slack. That flexibility exists with Kiro no matter where you are inside of your project, even if it's coming towards the end like this one did. You can always go back and ultimately work through those.

So if we're talking about some key takeaways here, it's important to know that these challenges were not just obstacles really for me to overcome. They were really a learning opportunity for me personally to understand how to best work with Kiro. I would challenge you as your developers or yourselves are working in these solutions to think about this and certainly take these on as well, even though they can be very frustrating, as a learning experience and moving forward too.

All right, so we've come to the end of our destination here, kind of full circle. At the end of our journey, we've had an ambitious goal that we wanted to, a mountain to climb so to speak, build a complete production-ready SaaS solution on AWS powered by a partnership with a GenAI, in this case Kiro. As you've seen, we were successful in this. We built this solution with a comprehensive control plane and agentic help desk as well with next-generation capabilities, but the product we built was only half the story. The other half is what we learned.

So first of all, we learned that quality is fundamental. We need to focus on quality as we're building these specifications. Second, and a part of this, clarity is the ultimate accelerator. The more clarity that you give Kiro in your requirements building, the better the solution that Kiro will build for you. And lastly, this is truly a partnership between you as a developer and Kiro as your AI assistant. It's a partnership and not a magic button. Kiro just can't magically make things appear for you.

The result of this, of course, is that we get a build out here that takes days, not weeks, and weeks, not months, which is pretty impressive in and of itself. And of course, as we're moving along, it's important to note that the future is now with agents inside of our IDE. Oh, and one last thing, SaaS isn't dead. You may have heard that it just smells like GenTech now, as the last sky that I'll leave you with here today. And I thank you for coming. We have many of those resources that Aman talked about earlier. Please feel free to grab these and use them in your own solutions.