[](https://example.saasstartupkit.com)
This web-app service includes the following pages and corresponding functionality:
[](../../resources/images/saas-starter-kit-go-web-app-pages.png)
### landing pages
The example web-app service in the SaaS Startup Kit includes typical pages for new customers to learn about your
service. It allows new customers to review a pricing page as well as signup. Existing customers of your SaaS can login
or connect with your support resources. The static web page for your SaaS website also includes a page for your web API
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-website-pricing.png)
In order for your SaaS offering to deliver its value to your customer, they need to subscribe first. Users can subscribe
using this signup page.
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-website-signup.png)
The signup page creates an account and a user associated with the new account. This signup page
Software-as-a-Service usually provides its service after a user has created an account and authenticated. After a user
has an account, they can login to your web app. Once logged in they will have access to all pages that require
authentication. This login page also uses some cool inline validation.
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-website-login.png)
The GO web app implements Role-based access control (RBAC). The example web app has two basic roles for users: admin
and user.
* The role of admin provides the ability to perform all CRUD actions on projects and users.
* The role of user limits users to only view projects and users.
Once a user is logged in, then RBAC is enforced and users only can access projects they have access to.
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-projects.png)
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-project-view.png)
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-profile-view2.png)
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-account-update2.png)
Users with role of admin have access to functionality that allows them to manage the users associated with their account.
This index page uses Datatables to demonstrate providing advanced interactivity to HTML tables.
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-users.png)
From the users index page, users can access the functionality to create a new record. This create page demonstrates how
a new record can be created for users. The create functionality also allows one or more roles to be applied for ACLs.
[](https://dzuyel7n94hma.cloudfront.net/img/saas-startup-example-golang-project-webapp-users-create.png)
In any production ready web application there're many concerns that should be handle it correctly such as:
* logging
* tracing
* error handling
* observability metrics
* security
All these responsabilities are orthogonal between each other, and in particular, to the business logic. In `saas-starter-kit` these responsabilities are handeled in a chained set of middlewares which allow a clear separation of concerns and it avoids polluting business-rule code.
We can separate existing middlewares in two dimensions: cross-cutting application middlewares, and middlewares for particular routes. Middlewares such as tracing, error handling, and metrics belong to the former category, whereas authentication/authorization to the latter.
If you want to dig into the details regarding these configurations, refer to `handlers/routes.go` where you can find the application middleware chaining, and the particular middlewares per route when adding handlers with `app.Handle(...)`.
### Routes
Every valid URL route can be found in `handlers/route.go`.
Notice that every handler is grouped by business-context (`Projects`, `Users`, `Account`) compared to sharing a single big struct. This allows to limit the scope of action of handlers regarding other actions that are far from its reponsability, and facilitates testing since less mockups will be necessary to test the handlers.
