AWS Open SaaS - Building a SaaS in the Open

[tvanhens]

Status: Proposed

Motivation

Building SaaS products is hard. Functionless can make this easier by providing a standard set of Serverless/Functionless blocks that can be deployed into AWS accounts to take care of the undifferentiated heavy-lifting. In order to identify these building blocks, we should build a SaaS in the open and blog about the process of building it from the ground up.

Desired Outcomes

• Dog-food functionless` new top-level API for building services to identify any shortcomings or blockers.
• Build some real-world examples of using functionless.
• Generate interest & traffic via a blog series documenting the process.
• Identify difficulties and candidates for SaaS foundational services to be built.

Approach

To limit scope the goal will be to build as simple a SaaS Product as is possible. The product is not intended to generate revenue, but we should build the minimum set of features such that it can do so. Readers should be able to follow the blog series and clone the code to be "up and running" with a minimal SaaS product that they can tweak to build their own products.

Potential Ideas

This list is not meant to be exhaustive. The feature set of the product should be as small as possible to ensure the focus stays on how to build out the foundational components.

Simple todo list with API - World famous todo app with simple GUI and the ability to create TODOs via API as well.

GitHub secrets scanner - Allows users to connect GitHub repositories and runs trufflehog on the git history to detect committed secrets .

GitHub driven TODO/FIXME/HACK list - Allows users to connect GitHub repositories and track all TODO, FIXME and HACK comments made in the code.

Milestones

Subject to change, but here is a rough roadmap of deliverables.

• Decide on product idea.
• Announcement blog post.
• Prototype shared-tenancy db design for product.
• Blog post on shared-tenancy db design and link to Open SaaS repository.
• Testing for db design.
• Blog post on DynamoDB integration testing strategies.
• Environment setup -- production, staging & devs accounts.
• Blog post on setting up accounts for environments as well as dev accounts.
• Add API, authorizer, users and basic user management.
• Blog post on Cognito, Authorizers and API Gateway.
• Build basic UI and connect to API.
• Blog post on UI basics and connecting to API.
• Build billing events and connect to Stripe.
• Blog post about billing and 3rd party services.

[sam-goodwin]

Love this idea. Definitely in favor of starting simple, but I wonder if we should also build a real revenue-generating service this way? Great way to share and market the product is to build it in the open.

[tvanhens]

I wanted to eliminate bike-shedding for the first pass. I 100% think we should hook it up to real billing (e.g. Stripe) but I don't think the focus should be on building something people would actually be likely to pay for. The foundations should be usable to fork and re-purpose for a more substantial idea once we build an initial version.

In other words, I think the part of this followers will find most interesting is what goes into making a SaaS product on AWS. By keeping the product scope as minimal as possible, we can zero in on delivering that with a high level of quality.

[sam-goodwin]

Prototype shared-tenancy db design for product.

Can you elaborate more on what you mean? Are you referring to record-level authorization on a single dynamodb table or one table per customer?

[thantos]

Also curious about this. What is special about a database in a SaaS?

[tvanhens]

If you are building the SaaS with a pooled tenancy model it leads to some interesting design concerns. The most important of which is how do you ensure that tenants cannot access data for other tenants at the IAM level.

The SaaS Factory team at AWS has a lot of interesting material on the challenges:

https://aws.amazon.com/blogs/apn/partitioning-pooled-multi-tenant-saas-data-with-amazon-dynamodb/

[sam-goodwin]

I like the GitHub use-cases - we'll want that capacity one day anyway. I've always wanted to look into what it takes to make a GitHub app.

[sam-goodwin]

Open SaaS repository.

Are you imagining a mono-repo of individual SaaS services available as Functionless applications? Would be a great way to show off Functionless and a good test-bed for connecting services like NPM packages.

[sam-goodwin]

Will we build this into the existing functionless repo or a separate one entirely? A separate repo makes sense in the long-run, but it may be slower for iteration speed in the short-run? Should we start inside funtionless for fast iterations while we build out support for the obvious gaps and move it later? Directing people towards the functionless repo would also be good for visibility and discoverability.

[thantos]

I think it should start in a new repo. Look like what a user would start with.

[sam-goodwin]

Environment setup -- production, staging & devs accounts.

This will be interesting. Would you use org-formation? Control Tower? Do it by hand? Or build a service?

[thantos]

Start simple?

[tvanhens]

👍 to start simple. To begin with, I think the accounts could be set up by hand and we could blog about the configuration. Down the line we can make the approach more elaborate, potentially filling in the gap with our own services and utilities if there are obvious deficits.

[sam-goodwin]

Build basic UI and connect to API.

NextJS on CloudFront would be a great outcome. CloudFlare could also be nice as a follow up? We would otherwise miss the preview capability that is super useful in PRs.

[thantos]

I think @cfraz89 said amplify may have some of the preview abilities or it would be pretty simple to build preview for cloudfront (ex: build CF url that points at the new s3 location)

[thantos]

Love it.

Other SaaS ideas:

1. Discord bot - authed with discord?
   1. Simple and cheap survey bot
   2. Milestone tracker - server users can track metrics and display them (ex: attendance for an
   3. AMA question tracker (like Say)
   4. Discord integration with cloudformation?
2. Formation planner as a service
   1. Connect to github and render a plan for CDK or CFN stacks based on the changes.
3. Uhh
4. Could we ask the community for ideas?

Milestones:

1. With the announcement we should publish a visual roadmap that we use in videos and blog posts to show progress.

Does shared-tenancy db matter for a SaaS? Isn't that just a database?

[tvanhens]

With the announcement we should publish a visual roadmap that we use in videos and blog posts to show progress.

Love this idea.

Does shared-tenancy db matter for a SaaS? Isn't that just a database?

Maybe not, I've been inspired by looking at webify's approach. Multi-tenancy could be achieved via deploying separate stacks/configurations.