Spectrum 3847 | How to write a build blog


Your blog should be informative and helpful to other teams. Consider what other teams want to learn about your robot design and build process. Avoid using jargon that other teams may not understand, and avoid sharing fluff.

What to post:

Design process:

Your brainstorming sessions, robot ideas in the early build season, CAD drawings, and simulations.


Instrumental in early build season- prototype videos, videos of old bots interacting with new game pieces, etc


Problems/obstacles you’re facing and what you’re trying to fix them

Lessons learned:

Things that went well, things that didn’t, and things you would do differently next time


Posts you can make consistently, like event recaps and weekly design recaps


Odds are that if you are training people on your team about something, someone else is as well.

When to post:

The Open Alliance recommends posting at least once a week. Posting short blogs frequently is preferred to posting long blogs every few weeks or months. Posting more often early in the season is more useful as those are the most critical days for prototyping. Posts during the early build and competition seasons are especially useful and engaging to other teams!


Use headings subheadings, and bullet points to break up your text and make it easy to scan. Include images and videos to illustrate your points.


Encourage readers to leave feedback and ask questions. More importantly, always answer questions people leave on your blog.

Good things:

Photos and videos.

At least half of your post should visually be photos and videos.

Not sharing all the details.

Choosing to leave everything simple 1) cuts down on your word count/blocks of text and 2) encourages people to ask questions, turning the blog into a discussion.

For example, in this post, we said we liked the “information diet” rule, people asked about it, and we sent several more messages about it. We could have chosen to elaborate fully in the first post, but it would have added several paragraphs of text and discouraged further questions.


Templates aren’t needed (they can make posts repetitive), but they can help start the writing process. For example, we roughly follow this template for event recaps.

Sharing resources on your blog

Having a section dedicated to all of your active resources, such as CAD, GitHub, photo library, etc, will make your blog the one-stop shop for anyone looking for more info about your robot

Spell Check

Draft your build blog on a Google doc and use Smart Spell Checkers such as Grammarly to get rid of any grammatical errors and to make it easy to understand.

Things to avoid:

Large blocks of text.

Instead, chop off unneeded sentences, rearrange them into bullet points or small paragraphs, and use helpful pictures to break up the text.

“Spoilers”/Hidden text.

Some people just won’t read it. Here’s an example of what we mean.

click me

Secret info only a few people will read.

Avoid posting mundane content.

A whole post that can be summarized as “We kept building the robot” isn’t valuable for the reader and will cause people to stop returning. Keeping posts interesting and useful will encourage readers to come back.

Ignoring Feedback:

If readers take the time to comment or ask questions, avoid ignoring them. Engagement is key to building a successful build blog.


I’ve been using this in various places to hide extra images that most people don’t need and take up a lot of extra space. I assume this is fine?

Generally, we would not use them, especially to cover pictures, as the pictures keep the reader engaged. It also requires the reader to keep clicking instead of just scrolling. If you feel like the images are taking too much space you can always make them smaller. We try to avoid hiding anything as much as possible.


Thank you so much for making this! Hopefully this improves the quality of build blogs all around. There’s a lot of build blogs where I think teams could improve a lot to make it more useful to readers, and hopefully this guide helps raise the bar for everyone.



Hate to say it, but if a build blog post I click on in season is just a wall of text, I’m about 99% likely to skip it/back out of the thread.

This isn’t trying to be mean or devalue a teams efforts when it comes to a build blog. There may be really really good info in that text, and it could be phenomenally well written. But in build season, I already have a ton of stuff going on. I’m usually reading the post on a break at work (limited time available), or at the end of a long/tiring night before bed. My time is limited, and I need to choose where I spend it.

Pictures allow me to quickly and easily deterimine if a blog post is relavent/interesting to me. If I notice a picture that really peaks my curiosity, I’ll likely stop, scroll back a little, and spend some time reading about the context of the picture.

Tl;Dr: MORE PICTURES = MORE BETTER in a blog post :grin:


What’s the best solution for media embedding?
I would think the best option for photos is just pasting/uploading them to CD, but for videos I’ve seen a few different options:

  • Upload to CD as GIF
    • I’ve seen this on Beşiktaş’ build blog a lot, and while it is really smooth I imagine it might take a lot of time, and they also load pretty slowly, at least for me. Also, no scrubbing is a bit annoying.
  • YouTube
    • Honestly probably the best option, but I’ve also had embed issues so I’m not sure.
  • Google photos
    • Not that good because you have to click on it and load in another tab to see the video
  • Alternative video hosting site
    • Not that good because of having to click on an external link

Are there any other options for video hosting that are better? What is preferred?


Any of the ways you described work. We host ours on our photo library (smugmug), which also loads on a separate tab. Whatever works best for your team,

Youtube is probably the most common/ best way, especially for long format videos above 1minute.


You used to be able (and still can for now) upload videos to Discord and share the link which embeds it on CD. Discord will be removing this ability in a few months however; you’ll still be able to do it but the links will expire after 24hrs.

We have done a little of all of the above. I think it partially depends on what’s easiest for the team and the type of video.

Short videos of tests work great as GIFs, We’ll convert some of the videos we take on our phones and upload them to our slack for the team so it’s very easy to upload those to CD as well.

For videos that are a little longer 1-5 mins I’ll normally keep them on our media sharing site and then post a screen shot with the play button on it so people know they can click it to watch. You can do the same thing for Google photos, etc.

For anything longer we’ll probably post it out YouTube channel and share the link. For youtube it helps to make sure you past the link on its own line and preview your post, to make sure it embeds correctly.

One thing we have discussed is using YouTube shorts for the shorter videos.

1 Like

Please don’t, it’s so much more of a pain to scrub and replay and repeat shorts than regular videos.


Thanks so much for this! I’ve been struggling to find ways to improve the quality of our build thread and this will be a massive help!!