Day 1 of building in public - I’m excited!
Last year, I built a proof-of-concept app to help me plan behavioral interview answers, practice them on camera, and share the videos with friends for feedback. I found it incredibly helpful in interview preparation but I had to put it aside when I started a full-time job at Amazon. I was laid off recently and now I'm using the extra time during my job search to build Prepple, a more production-ready version of my original app concept.
I’m building in public because I think it’s incredibly helpful to be transparent about the development process. I’ll share the insights I gain and obstacles I encounter along the way, in the hopes that it can help others. It's a shame that when we work for corporations, the NDA’s we sign mean that we rarely get to share our day-to-day struggles and triumphs. This is a rare moment in my career where I can share everything as it unfolds, and I'm excited to take advantage of it.
This week I’ll be getting my design docs in order and setting up key pieces of infrastructure for the core app.
What We're Starting With
Some parts of the framework are set up already: I have a functioning deployment pipeline, and functioning REST API gateway to a serverless Java Spring app. I also have a spiffy logo and have acquired the domain name for my app.
I’m using AWS CDK to define and provision my architecture and AWS CodePipeline to deploy. AWS CDK is an infrastructure-as-code system that lets you define CloudFormation stacks in a language of your choice, and then generate & deploy the templates to automatically provision and interconnect the AWS resources you need.
AWS CodePipeline integrates with GitHub, which means a deployment through the pipeline automatically triggers when new code is merged into the target branch of the repo on GitHub. The pipeline builds the CloudFormation templates, uploads code assets, provisions the infrastructure, deploys the code assets to the infrastructure, and runs various pre-defined tests, advancing to the next stage only if all required tests pass. My pipeline is pretty standard, with beta, gamma, and prod stages. (For more context, this article gives a great overview on what each stage typically involves: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/. Mine is a little different in that the alpha stage will be standalone and nonblocking, but I’ll go into more detail on the reasoning behind that in a later post.)
I also have a functioning boilerplate Java Spring app, currently running via a Lambda function and accessible by API Gateway. I’ve set it up so that I can test updates locally via the SAM CLI & Postman. It’s just the scaffolding of an app right now (one unauthenticated route, serving up “hello world”), but that’s all I need right now.
What's Next
Here's my game plan for getting started:
Highest priority: design docs. Coherent, well-written design docs will help avoid feature creep and ‘one-way door’ decisions (infrastructure or feature decisions that are difficult to undo.)
Next highest priority: AWS billing alerts. Before I provision any more resources in the Prepple AWS account, I’ll set up a Billing alert & spend threshold. Better safe than sorry!
Stretch goal: deploy minimal versions of a few other components the core app will need. I’d love to have a minimal auth service, a billing service, video ingest, and front-end running by the end of the week.
What do you think of this plan? I’d love to hear any thoughts, feedback, or questions you have. Leave a comment below or send me a message!
Top comments (0)