Hello there,

I truly hope that this email finds you well.

If you’re getting this email you are currently, or have been, a user, a customer, or a supporter of the Shubox service. Shubox is an app that adds a “nice” layer on top of the Amazon Web Services S3 to make uploading files to S3 easier.

I’m here to share the news that I plan on shutting Shubox down at the end of the year. It’s been a truly wonderful ride these last 10 (or so) years and I wouldn’t change a thing about the experience. I’ve been candid and honest elsewhere about what the journey has been like, but as with most things learning hard lessons is often the product of difficult, challenging, trying experiences.

The decision to shut things down has been in the back of my mind for several years and I am finally at peace with the prospect of closing these doors. It’s time to concentrate on myself, my family, and the long list of things that “fill my cup” instead of the things I feel I should or need to do.

---

What does this mean for you?

• Most everyone here hosts their own S3 bucket. This will remain yours, forever. Your files are yours and I will do nothing with them. No deleting. Nothing. • We will work with anyone who’s had Shubox-provisioned buckets move all objects to your own S3 Bucket. • I will work with anyone who needs guidance on how to move forward with transitioning from the Shubox infrastructure to a new solution. • I will be sending an email at the end of both October and November, with a report on how many files are being uploaded, transformed, etc. This email will act as a reminder that Shubox will shut down on New Year’s eve, December 31, 2025. (I hope this is enough lead time to make the transition.

If you have any questions, or need to work with me on timing, please respond to this email directly. It’ll come right to me.

I cannot thank you enough for your time, your trust, your collaboration, your support, and your interest.

🙏🏼️

Joel Oliveira Founder. Engineer. Janitor – Shubox

And I have written more about this on my personal website at joeloliveira.com, in case you’re interested in some further perspective. It’s been a wonderful ride. I wouldn’t change a thing. Thank you.

Imagine you have a large collection of data, files, “stuff”, you’d like to store safely - photos, videos, important documents, backups, you name it. Now, you could keep all of that under servers of your own control (EG: your own computer, external hard drive, or server), but what if you run out of space, your hardware fails, or something catastrophic happens? These circumstances are where a service like Amazon S3 comes into play.

Amazon S3 stands for “Amazon Simple Storage Service”. Think of it as a massive, super-secure warehouse in the cloud where you can store as much data as you need. It’s akin to renting a storage unit, but instead of physical stuff, you’re storing digital files. You can access your files from anywhere in the world, anytime, as long as you have an internet connection. I have seen it referred to as “the internet’s hard drive”, which, at this point, is a reasonable and accurate distillation. For a comprehensive deep dive into the history and technical scale of S3 go read this post at allthingsdistributed.com from Andy Warfield, VP and distinguished engineer at Amazon.

Amazon S3 is the brand name for what is more generically called cloud “object storage”. You might consider it akin to what “Kleenex” is to “facial tissues”, or what “Xerox” is to “photocopiers”, or “Google” to “web searching”. As a result, there are other object storage vendors out there: Cloudflare, Google, IBM, Wasabi, and DigitalOcean to name a few. There are also open source solutions like MinIO or Garage.

It should be noted, however, that Amazon’s S3 is the originator of this space. They created the technology, the concept, the utility, and should be afforded the respect and admiration for their innovation.

So, what is a “bucket”?

Considering Shubox is in the business of providing you buckets on-demand - you should know! A bucket is a container for objects stored in S3. If S3 is a giant warehouse, then a bucket is your personal, ever-expanding, storage locker. A bucket serves as a means of keeping companies’ and individuals’ data sequestered away from everyone else’s.

Why is it useful?

• Scalability: You can store an almost unlimited amount of data. That “storage unit” analogy? Imagine it could expand, on demand, as soon as you need more space.
• Security: Amazon S3 will keep your data safe. They’ve got loads of security measures in place, so you don’t have to worry about your data getting into the wrong hands.
• Accessibility and Sharing: You can access your data from anywhere and easily share it with others. Permissions are flexible and robust enough where you could go from “world readable” to “restricted to specific Amazon roles and users”.
• Affordability: The cost is inexpensive to start (think pennies) until you reach a considerable scale of storage and data transfer.

What are some example use-cases?

• Backup and Storage: This is the no-brainer. Whether you’re a big company or someone with a lot of digital photos, S3 is great for keeping that data safe, and off-site.
• Website Hosting: Have a website with many images and/or videos? Storing and serving them via S3 is more efficient and reliable than keeping them on your own servers.
• Big Data Analytics: Companies can store massive amounts of data on S3 and then use other Amazon services to analyze this data to gain insights.
• Disaster Recovery: In case something goes wrong with your primary data storage, having a backup on S3 can be a lifesaver. It is, effectively, an insurance policy for your data.

In a nutshell, Amazon S3 is a versatile, super-sized digital storage unit in the cloud. It’s an essential tool for anyone dealing with significant amounts of data, whether for personal use or business. And with its pay-as-you-go pricing, it is also wallet-friendly. If you’re still wondering whether you should use it, this post at Onixnet sums it up rather succinctly:

If you’re still not sure whether Amazon S3 is right for your organization, consider this: Amazon S3 is designed for 99.999999999% (11 9s) of data durability. With that level of durability, you can expect that if you store 10,000,000 objects in Amazon S3, you should only expect to lose a single object every 10,000 years!

I’m happy to say that you can instead jump ahead of all that if you’re using Shubox. You can have all the functionality at your fingertips, without the cross-browser debugging and headache’ery (that’s not a word, but I will allow it). I am happy to say that *webcam video recording* support is now baked into the Shubox JavaScript library.

What does that mean?

It means that your work consists of one HTML element [1]:

<div style="width: 640px; height: 480px;"
     id="webcam-video">
</div>

… and a bit of javascript that will do all of the heavy lifting for you. The following will create the video and canvas elements, and hook up click events to start the camera, start recording, and stop recording.

const video = new Shubox('#webcam-video', {
  key: 'SHUBOX-KEY',
  webcam: 'video',
  success: function(file) {
    console.log(`File ${file.name} successfully uploaded!`)
    console.log(file.s3url)
  },
})

The size of the video will be predicated on the size of the #webcam-video element. Clicking the element will start the camera. Subsequent clicks of the element will start and stop recording the video [2], followed by its being uploaded to your bucket.

Of course, that’s not all you are limited to. You may customize things to suit your user experience with options to tie the different life cycle events to other elements that may trigger them, and callbacks for different points of that life cycle. For example:

const videoWithOptions = new Shubox('#webcam-video', {
  key: 'SHUBOX-KEY',
  webcam: {
    type: 'video',
    startCamera: '#video-start',
    stopCamera: '#video-stop',
    startRecording: '#video-record-start',
    stopRecording: '#video-record-stop',
    audioInput: '.shubox-audioinput',
    videoInput: '.shubox-videoinput',
    cameraStarted: (_webcam) => {
      console.log("camera started")
    },
    cameraStopped: (_webcam) => {
      console.log("camera stopped")
    },
    recordingStarted: (_webcam) => {
      console.log("recording started")
    },
    recordingStopped: (_webcam, _file) => {
      console.log("recording stopped")
    }
  },
  success: file => {
    console.log(`File ${file.name} successfully uploaded!`)
    console.log(file.s3url)
  },
})

I’m happy to say that video recording is already being used by our friends at FutureMe where the Pro users are now able to record videos of themselves and send them into the future where the past versions of themselves can impart some old knowledge … to … themselves? I’ve confused myself.

Anyway.

If you’d like to see for yourself how this works, I also put up a small demo at Codepen. Give it a whirl, and let us know what you think on twitter!

Notes

1. The size of the div will be what determines the size of the video. I suggest sizing it to one of the common video aspect ratios - 4:3 or 16:9.
2. Format of the video depends on which web browser you are using. If on Chrome or FireFox, the video will be in webm format. If on safari, it will be an mp4. For more details see the source code for how the codecs are chosen.

He replied that “that is a remnant from the days I allowed people to take photos of themselves and attach them to the letters they’d send to themselves in the future”. It was a Flash component that interfaced with webcams.

We bandied around the idea that with the native controls available in browsers these days he, we, could replace that old relic with good old JavaScript.

“Why don’t you build that right into Shubox? Think you could?”, he asked.

Think I could? Was that a challenge? Well. Challenge accepted.

That little feature is now released to npm with version 0.3.0 of the Shubox JS library. It’s a preliminary take on support for webcam(s) where there exists some opportunity for further refinement and growth. Things to be added in the future — selecting from available cameras, video and audio support, event lifecycle callbacks, etc.

To give you an idea of what it takes to get this set up, let’s show you a little code. If we have a div that’s properly sized to hold the camera preview:

<div id="webcam-photo"
     class="webcam"
     style="width: 640px; height: 360px;"></div>

<script type="text/javascript">
  new Shubox('#webcam-photo', {
    key: '[shubox key]',
    webcam: 'photo',
    success: function(file) {
      console.log(file.s3url)
    },
  })
</script>

Done! That is it! If you’ve set up your bucket correctly, clicking the div will start the camera. Clicking it again will take the photo. And then finally upload it to S3.

For more information, documentation, demos, gifs, visit the GitHub repo and take a look! If you’d like to see this in action head over to FutureMe and write the future you a letter. Attach a selfie while you’re at it!

The Shubox mission from the beginning was simple - make it easier to get any old arbitrary file from your computer or mobile phone to the biggest cloud storage player in the world, Amazon S3, without having to hook up all this boilerplate, and with flexibility and flair in the user experience.

The upload from browser to S3 was table stakes. That was a given. That will never change. Shubox will always be stupid-simple. That last part, however, has been an evolving piece of the puzzle. In order to accomplish the “flexibility and flair” part our users need a javascript library that provides the right tools in order to make things flexible, while fitting the experience in your mind’s eye.

Until now(ish) we had the foundation to do this, and it was fine. We had a javascript file generated specifically for each of our users’ domains. There were a few custom bits and bobs injected into the JS that made things work. Over time we noticed this wasn’t entirely scalable, and not entirely conducive to having a fun development experience on our part.

I won’t belabor any further with the “why’s” and “how’s” things needed to change because of course there are plenty. Instead let’s talk about the great things that come with the new library as a way to illustrate how this shift will benefit not only Shubox but YOU, the every day developer.

1. It is written in TypeScript! It can’t be understated how the marriage of a strong type system and superset of JavaScript have provided such a wonderful and comfortable development environment. Once things are all wired and working together I can say that “developing in JavaScript” is an absolute joy. Setting up Webpack and all the tooling is another story, but that is another (blog) story for another (blog) day.
2. It is now a package on NPM. That’s right, Shubox is finally joining the JS revolution and is distributed through the NPM package registry. Until now the philosophy had been to make Shubox a standalone script file, unique to your project/domain (per the note above) - just include it in your HTML and you’re off to the races. The downside to this is that approach is analogous to purchasing a horse and buggy in the age of cars. Single page applications, react, vue, angular, et al, don’t work that way. So, it was beyond the time to get with the program.

3. There are many new features. Let’s talk about some of the new ones:

   • Transform completion callback. When your processed images are created, or new file formats are generated, you can watch for existence of those files and fire a callback function to do whatever you’d like.
   • Support for a CDN instead of amazon’s bucket URL. Resulting files can now be referenced via your chosen CDN hostname - cdn.mydomain.com instead of s3.amazonaws.com/my-bucket.
   • All provided options are now passed along to Dropzone.js. Previously there were only a subset of options moved along to the Dropzone instances.
   • You can now specify the exact S3 object key for (an) uploaded file(s). Very useful when you know exactly where a Shubox dropzone should end up, named specifically to your liking.
   • And more … the options, new and old, are all available to check out at GitHub.
4. It is open source! That’s right. The Shubox TS code is all available and open at our GitHub repo. As is this blog, mind you. Let us know over there if there are any issues, comments, feature requests.
5. There is more documentation – a LOT more documentation. With the guts of everything on GitHub the barrier to shipping new docs with the features is virtually nonexistent.

The JavaScript that’s been carrying the work-load up until now will continue to live on for several more months until the new library makes its way to a 1.0 version. Needless to say, it will be a little while. We will not be pulling those files off our CDN and will continue to support them. That being said - we would still encourage you to try out the new version!

Suffice it to say, it’s been a journey getting this new library whipped into shape to the point where things felt good getting out there. All of the demos at Codepen have been updated to use the new library – some with the new features I outline above – so we invite you to kick the tires over there. Or check out the code at GitHub and to let us know what you think at our twitter account, or email us directly at team@shubox.io. We’re all ears!

The basic way to choose image types

For the past few years, the easiest and most straightforward way to choose your image type was between photographs and graphics. As a quick rule of thumb: photographs should be JPEGs and everything else should be PNGs. There are two exceptions:

1. If you are using an animated image (or video converted to image), definitely use a GIF
2. If you’re using images like icons (where they need to scale with your typography), see if you can convert that image to an SVG (Sketch is easily the best at converting to SVG)

There are a bunch of other image formats, such as BMPs, EXIFs, and TIFFs, but those have largely fallen out of favor even though they still technically work.

For years this advice would serve you well. But the web is still evolving and there are new file formats to consider when putting your images on the web.

The advanced way to choose image types

Recently there has been a rise in next-generation image formats to make the web lighter and more accessible. Unfortunately, the rules for choosing these formats is not as straightforward as it once was. Here are the 3 main types of next-gen image formats you should be considering when uploading your next image onto Shubox.

JPEG 2000

JPEG 2000 is a newer incarnation of the JPEG format. The primary purpose of the format is to preserve metadata through radical compression techniques. While most traditional JPEGs have a limited set of metadata for photographs, JPEG 2000 uses structured XML to include a vast array of metadata information.

This is useful for applications like film and medical imaging because a great deal of data needs to be associated with the image. For example, film stills need to store information about high dynamic range and different color spaces. Medical imaging requires absolute precision in image clarity in spite of the large volume of data. With JPEG 2000, you can encode these files completely losslessly, with good-enough compression performance to make transfer acceptable.

Even if you aren’t in the film or healthcare industry, you can take advantage of these new compression techniques in your current JPGs by switching to JPEG 2000. Excluding these specific applications, as a general alternative to JPGs, JPEG 2000 is still superior because it can be compressed down even further than a standard JPEG with less loss in visual quality. With a smaller file size and better visual quality, JPEG 2000 is a total win over the standard JPG format. There is one caveat: if you are writing for the web, JPEG 2000 is only supported on Safari, so it will only benefit your customers on Macs, iPhones, and iPads. As long as you use the other two formats that follow, you should definitely consider JPEG 2000 in your arsenal of image formats.

NOTE: As of May 21 JPEG 2000 is a supported format by Shubox. You can now convert JPGs and PNGs to JPEG 2000!

JPEG XR

JPEG XR is yet another next-gen JPEG format and a close cousin of JPEG 2000. JPEG XRs application is less intense than JPEG 2000 and was designed in many ways to be the successor of the standard JPEG format.

The main benefits of JPEG XR over the standard format are for enhanced support for HDR imagery. While the original format uses 3 color channels in a bit-depth of 8, JPEG XR supports multiple color formats like monochrome and CMYK and supports bit-depths of 16 or greater. It was also designed from the ground up to support better compression techniques. In other words, it is like JPEG on steroids.

While this is a more practical and versatile file format compared to JPEG 2000, it suffers from the same adoption blunders by being available on only a limited set of browsers. As of this writing, JPEG XR is only supported on IE, so it will only benefit your customers on Windows machines running some form of IE.

Combined, these two formats will cover all of your photography needs across the majority of devices. But what about PNGs? And what about open source browsers like Firefox and Chrome?

WebP

WebP is the open source answer to the next generation of both JPGs and PNGs. The primary application of WebP is the web and is routinely 25% smaller than both optimized PNGs and JPGs.

Because of its web roots, WebP is immediately available in both Chrome and Opera. In addition, WebP has animation support and can be a great replacement for GIFs as well. cwebp is a super easy command line tool to quickly convert your JPGs and PNGs into WebP images, which makes it even easier to convert into than JPEG 2000 or JPEG XR. Luckily, Shubox automates this as well and will let you convert your images into the WebP format when you upload them to S3. How cool is that?

Like the other formats, the major flaw is in browser support. As I mentioned, this comes supported out of the box by Chrome and Opera, but that’s it (well, and a bunch of other Chromium-based browsers too).

Again, the thing to remember with next-gen photographs is a triple threat approach. If you want to put a photo on the web, you need to use JPEG 2000, JPEG XR, and WebP.

What about Firefox?

If you overlay all of the browser support links, you’ll notice that Firefox is the only browser to not support any of these formats. Mozilla has tried to implement not once, not twice, but thrice! Technically, they claim it is being worked on and has been assigned and updated within the last 2 weeks of this writing, but I’m not holding out any hope in the near future. In the meantime, keep the original image you used to create the previous three formats, and use that as the fallback for any browsers or devices that aren’t supported.

How to combine everything to get a total solution

While the next generation image formats above are not supported by all browser vendors there are some tactics you can employ to get these images to your users in the best format possible.

• Utilize responsive images. Libraries like Modernizr and Picturefill can detect what is supported by the browser at runtime, and polyfill responsive image support.
• Use srcset to select each file type. Srcset is an image property that lets you toggle between images based on various criteria, such as high-resolution displays which are typically only seen on newer laptops and mobile phones.
• Use external services to convert your images for you. Shubox will automatically create WebP images for you, while Onthe.io and MyGeoData will convert JPGs into JPEG XRs and JPEG 2000s, respectively.

At first blush it might seem like a lot but consider an incremental support approach. With all of these image formats to choose from, you can experience the web of tomorrow, today!

In addition to sharing some philisophical DNA, there are some commonalities in the type of work they do – delegating work from a customer’s website to an external service. FormKeep offloads the work done to receive, persist, and deliver form submissions. Shubox handles file and image uploads to the cloud (S3 specifically, of course), manipulation of those images, and delivery of that information to your applications.

Where and how can both help simultaneously? Let’s explore that.

Say you are a small business or startup. You’re growing fast and recruitment and hiring are a high priority. You probably want a form on your site with a couple of fields, maybe with name, email, cover letter, and some way for your candidates to upload a Word, PDF, LaTex doc, or plain text (yeah!). You have a statically generated site, or managed hosting of some sort, or your developers are completely allocated on the core business and not able to work on that side of the business.

Other than running a power play around your dev managers and wresting a developer or two away from “business” for a day or two, what could you do?

Using FormKeep and Shubox and a little know-how you can get this done in ~20 minutes.

How?

Let’s start with the form

<form action="https://formkeep.com/f/xxxx">
  <input type="text" name="position" placeholder="Position Applying For">
  <input type="text" name="name" placeholder="Your Name">
  <input type="email" name="email" placeholder="Your Email">
  <textarea name="cover_lever" placeholder="Cover letter contents..."></textarea>

  <button type="submit">Apply for Position</button>
</form>

If you’ve signed up for FormKeep and are pointing to the endpoint they assign you. You’re done with that part. Configure things on their dashboard – what email to send new submissions to, integrate with Zapier, etc – and that’s pretty much it.

How about the resume?

<form action="https://formkeep.com/f/xxxx">
  <input type="text"  name="position" placeholder="Position Applying For">
  <input type="text"  name="name" placeholder="Your Name">
  <input type="email" name="email" placeholder="Your Email">
  <textarea name="cover_lever" placeholder="Cover letter contents..."></textarea>

  <input id="resume"  type="text"  name="resume" placeholder="Click to upload resume">

  <button type="submit">Apply for Position</button>
</form>

<script src="https://js.shubox.io/v1/id-for-your-local-dev-server.js"></script>

<script>
  new Shubox("#resume", { textBehavior: "replace" })
</script>

If you’ve signed up for Shubox you’ll be able to try this out immediately on localhost. Above, you will see that you would add the script tag for your development server. (Pro-tip: you’ll find that in your dashboard). Then, using the Shubox javascript lib you can configure input#resume to start the “attach and upload file” process once the input field is clicked. When you select your file it will upload to S3 and populate the contents of that form field with the URL to the file.

And that’s it!

After someone fills out the form, uploads a resume, and submits it, it will send all that information to FormKeep, including the URL to the uploaded resume and, depending on how your FormKeep account is configured, will email you that same information.

Note: Once you deploy your website to your production domain you *will* need to configure a “domain” in the Shubox dashboard for whatever hostname you use. For example, if your final website lives at acme-co.com you’ll need to set that up in the Shubox dashboard

Often when dropping into a new Rails app I’ll notice that models, specs, and factories will be the lucky bearers of the related database table schema thanks to the annotate_models gem.

The annotate_models gem is a great tool for providing visibility into the underlying structure of your database tables.

To that, I say “👍” !

However, there are some downsides. They’re not necessarily malevolent or problematic, but more speedbumps along the road of your development process.

To wit:

1. It’s noisy at the top of important pieces of your code. Opening a file, being met with a wall of comments, and spending time to get to the meat of a class - it’s a speedbump. I ask you to ask yourself - how often do you really need to reference the columns and structure of your table? I’d guess “not so often”. It’s not that big a deal, but over time when your models grow in size it’s not unfathomable that your editor buffer, on first open, could be nothing but the contents from annotate_models.

   If you use vim and tpope’s vim-rails package you can get to your model’s schema you can get to this information quickly already. :Eschema table_name will take you right there. Example: :Eschema users, :Eschema posts, etc.

   If you use Atom there are plugins that will assist with this -

   • atom-rails-model-schema
   • atom-rails

2. A migration should result in 2 files staged in Git. The new migration, and an updated schema.rb or structure.sql. Instead, with annotate_models you end up with those two, plus: modified model, factory, and spec – for each model you update. To me that’s an unnecesary halo effect.

3. Last but not least — and, arguably, most annoyingly — if you or a teammate neglects to check those updates into git, the next time someone runs a recently checked in migration, your local files change modifying files that have nothing to do with the work you’re going to check in.

I will stop there with my humble request that you reconsider using annotate_models and get into the meat of what I feel is a helpful tool for your project(s). Enter rails-erd …

Rails ERD (Entity Relationship Diagram)

What is an “Entity Relationship Diagram”? According to techopedia:

An entity-relationship diagram (ERD) is a data modeling technique that graphically illustrates an information system’s entities and the relationships between those entities.

rails-erd is a utility gem that will generate a PDF with a diagram of your models, their columns, and the relationship between the models. It looks a little something like:

Per the directions on the project’s repo:

1. Make sure graphviz is installed:

   • brew install graphviz 🍎
   • sudo apt install graphviz 🐧

2. Add gem "rails-erd", require: false, group: :development to your application’s Gemfile

3. Run bundle exec erd

You should have a PDF in your app root waiting to be opened now!

For extra credit you can set up your app to generate a new erd after you’ve run new migrations.

bundle exec rails generate erd:install

Your information now resides in that one pdf, unlike annotate_models. No polution of all your files. One file that can be gitignored if so desired! Huzzah!

In the grand scheme of things, the gripes I present above are miniscule. I’d absolutely concede that. It’s really not that big a deal. However, if you’re on a project using annotate_models and you’re in the middle of a rebase having to reconcile the merge conflicts from that gem across several files? I hope you’ll remember this blog post.

Photo by Ghost Presenter on Unsplash

As a developer who uses more than their fair share of services as a means to shave time off from doing task X in order to get feature Y done, I know what it means to get to a *win* as fast as possible. Push-button successes, right? The nice touches that get you to “done”.

In light of that, Shubox has put together a “sandbox” bucket that can be used immediately with your local development environment upon registering your account. You no longer need to get your S3 bucket ready to go in order to test the main Shubox functionality. As long as your local app/web server is running on localhost/127.0.0.1/0.0.0.0 then you’re ready to get started.

All that’s left is to place our javascript library in your html, and hook Shubox into your element(s). Done.

For more information and instructions sign up, or sign in, visit the sandbox page, and get ‘ta uploadin’.

It’s been several years since I wrote the first line of code for Shubox. From that first hacking session until today my goal has always been to make something that would be useful to me, and people like me — people who work on the web. It’s always been, first and foremost, a scratch of my own itch. To that point I feel that I’ve succeeded. I use Shubox all the damn time.

When I would work on client projects and the need to upload, resize, do much with AWS S3, then I would suggest using Shubox and be done with it. It worked. It saved me a tremendous amount of time. For those clients, it was also ultimately free! Most of their use cases were esspecialy unique and I was able to learn a lot about what my they needed vis a vis Shubox. The trade — feedback for service.

It was an easy justification because most of these clients weren’t in need high volume file or image uploading. As a result a conversation similar to “You know, I have this service that you should pay $49 a month for. Yes, to upload a few photos for the 3 or 4 products you add to your catalog every month” never happened.

In a business’s lifecycle there are long stretches where needs evolve. Coming out of the gates for an initial launch usually doesn’t need a Kubernetes cluster, distributed messaging systems, hadoop, tensorflow, bloopity bloop, whatever. A few dynos on Heroku, droplets on DigitalOcean, or VPS’s on Linode should be ok. Exception handling, google analytics, Sendgrid, and maybe a Squarespace account would round out a lot of the first absolute must-haves.

Most of those things have something in common. You can start out using them for free. Of course some of the leading services people could reach for in Shubox’s space also have free tiers.

I won’t belabor the point - Shubox should have a free tier. Shubox is something that people with low usage, or are just starting out, should be able to use for a while to see if it’s right for them. This much is true.

As a result, as of today, anyone who signs up for an account on Shubox will be able to use it free, forever, or until they need more, bigger, better service. For more information on the different tiers, visit the pricing section on the home page, or get in touch down below and to the right with the “Send a message” button! I’ll be on the other end.

Merry Christmas! Happy Chanukah! Happy Kwanzaa! And a lovely Festivus for the rest of us.