This week I'm re-architecting and moving @snap_as from a separate application into our single @write_as application. Here are a few thoughts along the way.

A little background: this is driven by Google Cloud being a very, very bad cloud platform to build on as a small team.

We tried it in 2016 as an experiment, and a series of service deprecations since then have caused us downtime and meant us ultimately offering a stable, but stagnated service.

Deployment got harder as their platform shifted beneath us, and one day recently our entire site was replaced by a simple message that said, "We no longer support Go 1.9." That was a fun day!

@snap_as was also the first product we launched separately from @write_as, and it was built on the assumption that an entirely separate codebase would be best.

The idea was that the applications would share common components (, but would have separate application codebases and storage.


This might've been a good theory for building modular applications (as I'm hoping to), but in practice causes a ton of headaches for maintenance and end user experience.

Little problems came up right away:

- How do we share user data across platforms?
- How do we create common UI patterns while keeping distinct branding on each platform?
- How do we reconcile slightly-different uses of those shared libraries across platforms?

· · Web · 1 · 0 · 1

So, starting with @submit_as, we built the functionality into the codebase. There was still plenty of copy-paste involved, but we were able to launch this new product much more quickly.

Now instead of creating separate apps first, we're building them into first and then separating out functionality over time.

Sign in to participate in the conversation
A Bunch Tell

This instance is only for A Bunch Tell projects.