Case Study Writing

What is a Technical Case Study?

Case Studies are the holy grail of technical writing. It is a synthesis of documentation, technical blogging, and storytelling. At the Marcy Lab School, your technical case study will break down and outline--in great detail--the entire process of creating your project-- from the conception of the idea, to planning and implementation, and beyond!

Why Write a Case Study?

Typically, when a developer wants to share their coding project on the web, they host their code base on Github. If they deployed their project to a production environment, they have a website or some public-facing version of their application. Those artifacts only tell part of the story! You worked hard on your project! And now, you will have the opportunity to share every step of the process in your technical case study.

A technical case study is a fantastic way to brand yourself on the web-- to companies, recruiters, hiring managers, and the general developer community. It documents your ability to solve problems, both technical and non-technical. In addition to showcasing your coding and implementation abilities, a case study showcases your technical writing abilities. Being able to code is important, but the ability to communicate your entire project journey makes it even better!

Finally, having a well-written, high-quality case study will elevate any project! It makes a project feel so much more polished because you, the developer(s), poured your time and effort into this beautiful piece of writing that both technical and non-technical personnel can appreciate and feel a part of.

Requirements

At the Marcy Lab School, we require that your technical case study be 1,500 to 2,000 words. It might sound like a lot, but that's the same amount of content as a few of your Marcy Lab blogs.

Furthermore, you can refer back to your previous project submissions as you can reuse some of that material. This includes, but is not limited to, your project proposal, your wireframes, ERD diagrams, and any other planning materials you've written.

Like your Marcy Lab blogs, your writing should be supplemented with screenshots of your project, code snippets, diagrams, stock images, technology logos, etc.

Finally, you can publish your case study on a professional blogging website, such as Medium or Dev Community. If you would like to go above and beyond, you can publish your case study on a custom website that you deploy. The following are examples of professional case studies hosted on their own website:

Potential Sections

So what information should you include in your technical case study? Every capstone project is unique. The sections in your case study writing may be different from another group's depending on the features or technologies you want to highlight. However, you should use the following format as guidelines. Below are some possible guiding questions that will help you write your technical case study.

Application Overview

  • What is your project?
  • What problem does it solve?
  • Why did you choose to build this project?
  • What inspired you to build this project?

Application Design Overview

  • What is your technology stack?
  • What new technologies did you learn for this project?
  • Why did you choose to use that technology?
  • What is the architectural design of your application?
  • What technologies did you use in your back-end?
  • What type of database did you choose and why?
  • What is your database design/schema?
  • What technologies did you use in your front-end?
  • What is the user flow of your application?
  • Did you use any third-party technologies that do not live in either your front-end or back-end? If so, what purpose does it serve?

Challenges and Implemented Solutions

  • What technical challenges did you encounter and what thoughtful solutions did you implement?
    • Note: You should focus on writing about your Implemented Solutions. When we discuss technical challenges, we only want to talk about the challenge that we overcame and found a thoughtful and good solution to.
    • It is not worth mentioning challenges that involved a simple solution (i.e. reading the documentation) or a solution that is part of the project-building process (i.e. learning a new technology was challenging).
    • Your technical case study should have at least one technical challenge and solution per member of your group, possibly more.

Extension Opportunities

  • If you had more time, what additional features would you build out?
  • What existing features would you improve upon?

References and Links

Don't forget to include references and links to other important resources pertaining to your project! Somewhere in your technical case study (at the end is a good choice), you MUST include:

  • Link(s) your public Github repositories
  • Link to your deploy application
  • Link(s) to your Linkedin profiles or other professional social media
  • Optionally, link any learning resources you used to build your capstone project (blogs, articles, etc.)

Additionally, you should link your published technical case study in the READMEs of your Github repositories.