Final thoughts on Buy v Build Integration Choices
Payments, Content Management, Key Generation
We have explored various decisions that a new entrepreneur needs to make in their MVP build-out. Until now for me, all of the choices were required and in many cases critical paths for my business. Here I am going to share a variety of other considerations that I think are optional to most people. It's important to point these out though as many integrators don't realize that there are off-shelf solutions that will fit 80% or more of their needs.
Selection Criteria and Considerations
- Does incorporating a third-party give me anything for free?
- Can I afford the integration?
- What would it replace internally if I build it myself?
- Is this integration core to my competitive advantage?
- Will I still own my customer if I leverage this third-party tool?
- Does it allow me to separate responsibilities away from engineers?
Every good engineer who has been around the block a time or two has made the mistake of building a content management system. It's an easy rabbit hole to fall into, at first you just start making a web page with a configurable block of text. Then you make it so you can define a few pages. All of a sudden you've fallen into the trap of abstracting out Content Management.
I analyzed a few of these platforms and have found one that integrate really well with Vercel and Netlify. It can trigger website updates upon content update (prioritizing separation of concerns for content creators + engineers) and also has very low cost (free).
They give you a very easy-to-use content management UI with the community tier and for simple applications, this can easily replace the need for Wix or SquareSpace if you want finer-grained control over what content is displayed on your custom application. You of course will have to style your application and theme it, but this will give a business-minded team member the ability to add content and offload that responsibility from your shoulders.
Payments and Subscriptions
If you have ever had to roll your own Payments or Subscriptions you know this is a huge amount of work. So obviously huge that a whole industry around Payments exists.
My Choice: Stripe
I have had to be a part of teams in the past that rolled their own Payments and Subscription features with low-level payment gateways before Stripe existed. I'm so thankful this platform is available. They provide a very developer-friendly approach to integrating Subscriptions, so good that in fact it probably warrants its own post with sample source code. I chose to use Stripe because I'd get all these fantastic analytics for free once I integrated my inventory and began marketing to customers (if I could get someone to successfully pay).
We leveraged a few integration points:
- Webhooks - Stripe called our webhook in our python backend passing a series of events like Subscription Payment Completed or Failed - this allowed us to provide API Keys to our users
- Low-Code Payment Gateway - we used this to offload and embed an interaction to capture the payment and store credit card information outside of our systems. Let Stripe own the security risks of housing high-value credit cards and user Personally Identifiable Information (PII).
Backup Plan: Braintree
I remember seeing the advertising for this startup in Brooklyn in 2014-2015 spray painted on a wall beside my favorite pizza place in Greenpoint. This isn't the exact one but you get the point:
This company has a reputation for building dead-simple to integrate payments prioritized for developers. They have a similar toolchain as Stripe like Recurring Billing, Robust Reporting, and Fraud Management. I think after spending a week building Stripe end to end I just didn't have it in me to complete the review of apples-to-apples comparison is given I was in get-it-done mode. If I were making a decision for a less-tactical operation I'd have built it out and compared the two. I do think that these are neck-and-neck competitors and they are aware of each other's pricing.
This was a feature I was really excited about that turned out to be overkill for my immediate needs. If you are in the need to build Machine-controlled, IP Restricted, or finer-grained API Key authentication for an API or Software platform, then you should consider a third party.
Otherwise, if you are just trying to provide some measure of security to an API you are testing with Beta customers, you may want to favor 2-3 lines of code to generate an SHA HASH and use something like FastAPI Dependencies to gateway to protect your API.
After a few days of integration work between Vercel and Stripe I opted for the latter above, but not after a lot of trying to make Keygen work with me. I'd give this platform another shot in the future because the reporting and customer service UI would be very beneficial when you think about the separation of concerns in the responsibilities of a growth company. If you choose something like Keygen you can have a CSR or Customer Success team member serve customers with problems without involving an engineer. If you do build your own feature you may have to include engineers for menial distracting tasks.
You get quite a bit for free here if you use this platform, but it will be more complex to integrate than generating a SHA hash. It will likely be creating more secure and revocable API keys though.
There are plenty of administrative features to explore in this toolchain and as you can see a great performance dashboard you can use to offload and incorporate customer success staff down the road.
HackJob DIY Approach
Sadly I just ran out of time to work on this as it was not critical to my ability to prove I had a business opportunity. So I opted to use this little block of code in an API to generate these on successful payments from Stripe. I wish I had saved the link of the original author, if anyone knows let me know and I'll link back to their GitHub or StackOverflow post.
"""Generate cryptographically strong pseudo-random numbers suitable for
managing secrets such as account authentication, tokens, and similar.
See PEP 506 for more information.
__all__ = ['choice', 'randbelow', 'randbits', 'SystemRandom',
'token_bytes', 'token_hex', 'token_urlsafe',
from hmac import compare_digest
from random import SystemRandom
_sysrand = SystemRandom()
randbits = _sysrand.getrandbits
choice = _sysrand.choice
"""Return a random int in the range [0, n)."""
if exclusive_upper_bound <= 0:
raise ValueError("Upper bound must be positive.")
DEFAULT_ENTROPY = 32 # number of bytes to return by default
"""Return a random byte string containing *nbytes* bytes.
If *nbytes* is ``None`` or not supplied, a reasonable
default is used.
>>> token_bytes(16) #doctest:+SKIP
if nbytes is None:
nbytes = DEFAULT_ENTROPY
"""Return a random text string, in hexadecimal.
The string has *nbytes* random bytes, each byte converted to two
hex digits. If *nbytes* is ``None`` or not supplied, a reasonable
default is used.
>>> token_hex(16) #doctest:+SKIP
"""Return a random URL-safe text string, in Base64 encoding.
The string has *nbytes* random bytes. If *nbytes* is ``None``
or not supplied, a reasonable default is used.
>>> token_urlsafe(16) #doctest:+SKIP
tok = token_bytes(nbytes)
One nice little addition I used was YoPass to help me exchange secrets with my test users. Sometimes I'd need them to provide me a secret token like a Discord token or I'd want a safe way to send them a URL to an encrypted one-time secret. This platform gives you exactly that and is even easy to spin up in a Kubernetes Environment so you know that the secrets aren't saved in someone else's database.
Check it out!
This concludes my analysis of the tools I integrated for Foliofficient as I explored the business through MVP building. I'm sure there are 100s of other integration choices to make and hopefully, by reading if you read this far, you got something in terms of framework out of reading.