Building a B2B SaaS Prototype

We all know working on a team is a lot different than working alone. The tools you use are often quite different. With our work tools we can’t have a single point of failure. We don't want team accounts under one person’s email, we use a centralized email. We don't want payments on an individual’s card, we use a corporate card. We don't want site-outage pages routed to one teammate’s phone, we use PagerDuty.

With the rise of two factor authentication (2FA), we run into an issue. 2FA adds security but it creates a single point of failure where you need one phone. This means one person gets all the texts/calls.

In steps my solution. To have one phone number for a whole team. All received messages get forwarded to the shared corporate email.

NOTE: This blog will be covering the proof-of-concept and prototype of the idea. In the next few weeks I’ll likely build out a full version of this with more security.

Before I jump into how I built things, I'll note there is an easy way to do this. Though it’s less customizable. The solution is to make a "burner" Gmail account. Using that account get a free Google Voice number. Set it to forward messages to the shared email address. This works but isn’t customizable and GV often doesn’t work with corporate email addresses.

Building it

My solution is simple and I built it all using tools and services offered by Twilio. Come along for the journey and let’s dive in.

To get started, set up an account with Twilio. We’ll get some free credits and we’ll get a phone number which we can use for a year until we have to pay.

The first thing I built was a simple function using Twilio’s Function feature. This is a stateless function that you can reuse across apps and flows you build. The next tool I used was Flows. This is a drag and drop no-code workflow builder. The last thing I used was SendGrid, Twilio’s automatic email service to forward the messages.

Next thing to setup is SendGrid which will allow us to send 100 free emails a day using an API. Create an account, confirm your email and then go to settings > API keys to create keys. Keep this key somewhere handy for a few minutes.

Next you’ll need a verified sender which can be setup here. Note: use a regular Gmail email, a work email will likely block requests from this service. Time to start making this work!

Here is where I used Twilio Functions/Services. It's possible to do this on my own server but I kept it in their ecosystem for simplicity. On the Functions tab I created a new service and then added three new environment variables.

  1. SENDGRID_API_SECRET - the API key from before
  2. TO_EMAIL_ADDRESS - the email you want your messages forwarded to
  3. FROM_EMAIL_ADDRESS - the verified email address from above

Then in dependencies we’ll need to add a package to send emails. I added `@sendgrid/mail` and the version `7.6.0`. Now it’s time to get coding! We want to take in the message we got, extract the text and forward it to the set email. You can copy paste this code:
https://gist.github.com/mgaspari/373ea55692f03569c90c95185f693d26

Make sure you save and “deploy all” and you should be all good to go!
Now it’s time to incorporate this function into a Flow. We want to trigger the function above every time a message comes in. Go to Functions here and create a new Flow starting from scratch.

Now you want to drag in a Run Function Widget and connect it to the “incoming message” tab. It should look something like this:

In that function tab we want to use the Function we built before. It should show up in the dropdown and should look something like this:

All we’ll need to add is function parameters to pass proper data to the function. It should look something like this:

Now hit publish and we’re almost done!

Go to active numbers and we’ll select “Studio Flow” and select the flow we created. Hit save and everything is wired up! Here are some examples of this working:

Debug

Sometimes the whole flow can take a minute. If you want to debug there is a Monitor section in the Flow and Functions UI. You can see if errors came up or if texts and API calls completed:


Check the SendGrid email Monitor section here.

Conclusion

This was a fun project to work on and it has real uses. For the next iteration it would be awesome to set this up on Heroku or a small AWS server and make a full SaaS product. I’d integrate Stripe. allow users, and make it a web app. Stay tuned!

These Twilio posts were super helpful in creating the prototype: Post 1 and Post 2.