Building the True Cost Calculator - A design and engineering process deep dive

We Built a Coding Bootcamp Calculator To Help Prospective Students

Coding bootcamps are immersive educational programs that focus on software development. While the premise of a coding bootcamp is simple - enroll, learn, launch a career - selecting the right bootcamp is not. Prospective students have many constraints to consider, the most restrictive of which are program length and cost. We've spoken with thousands of prospective students and understand these constraints. These constraints became the foundation for the calculator.

Program Length: Most full-time programs promise to turn a new student into a junior developer in 12-18 weeks. Part-time programs make the same promise, but offer a longer, and sometimes more flexible schedule.

Cost: The price of the bootcamp is the most obvious cost to consider, though depending on the coding bootcamp, a student may incur a loss of income while enrolled. This can add tens of thousands of dollars to the overall cost of the program.

We built the coding bootcamp cost calculator to help students compare bootcamps in top tech cities based on program length and cost. By optimizing the bootcamp search for these two constraints, the calculator helps prospective students find the best bootcamp, for them.

Gathering the Data

We gathered data that would provide the most meaningful outputs for prospective bootcamp students who want to start a new career. We collected data for tuition cost, length of program, and the average salary for a junior web developer in select cities.

Geographic Focus: We gathered data from the top tech cities where coding bootcamps are located: Atlanta, Austin, Boston, Chicago, Denver, Los Angeles, New York City, Seattle and San Francisco Bay Area.

User Intent: We decided to only include career-oriented bootcamps in the calculator results to increase signal and reduce noise. We were diligent in our research of bootcamps to ensure that we represented them fairly.

Data Normalization and Assumptions: After assessing program length and cost data for each bootcamp, we discovered that the data needed to be normalized:

  • Pre work, part time, and full time features required consistent definitions, as they all contribute to the length of the program.
  • Tuition was variable based on program length and the fact that some bootcamps take a percentage of salary when a student gets hired.
  • The average salary of a junior developer was pulled from job listings on

We did not include certain factors that could influence overall cost, namely relocation and financing options. We felt they would be relatively minor and too difficult to normalize.

Designing the Calculator

Our primary requirement was that the calculator be embeddable, allowing the final product to be shared in articles and blogs discussing the cost of coding bootcamps. An embeddable calculator needed a fully responsive layout. We asked ourselves: How might we create an online calculator that is visually interesting and easy to understand, but responsive at any size? Our design strategy followed these two guiding design principles:

The representation must be visually interesting and easy to understand:

  1. Use a harmonious, but energetic color palette
  2. Leverage familiar, cross-cultural design patterns
  3. Emphasize legibility to limit data density

The output must be adaptable to any size:

  1. Only use mobile friendly interactions
  2. Design for a fluid, percentage-based layout
The Design Process


Moodboarding is a great way to establish the feel of a project, to collect inspiration, and establish your own interpretation. We used moodboards to focus on visually compelling and functional data visualizations.

Our moodboard with images pulled from Pinterest and Dribbble shots.


Our sketching phase is intentionally open and experimental. We knew that we needed:

  1. An input page for users to specify their location and current salary
  2. A results page containing bootcamps, and their program details, for a given location.

In the interest of iterating quickly, we began our design process at the same time that the data was being collected. We had to make assumptions regarding missing information, such as outliers in the data (ex. the longest and shortest lengths, highest and lowest tuition, etc).

A sampling of our pencil sketches.

We explored various layouts for the results page. Bloc’s design team seriously geeks out over data visualization, but this wasn’t really the time to make an intricate, ground breaking data vis piece. Users needed to be able to interact with it quickly and easily, and it needed to work at any size. Right away we found that most of the unique solutions were not the most flexible layouts. To be sure, we continued to explore through digital sketches.

Some of our digital sketches.

Bar graphs are a familiar way to show data, and they are digestible in a single glance. A one column layout containing horizontal graphs, virtually guaranteed that it would hold up at any size.

Typography is one of the biggest challenges in creating a responsive visualization. At first, we tried placing text inside the bars, but because we could never know for sure how wide the bars would be, we couldn’t be sure there would always be enough room for the encapsulated text. We scratched that and separated the variables on to their own lines.

We also chose not to reveal any content on hover. While this can be a nice way to save space and create engagement, it would require additional engineering work to adapt for mobile devices.

V1 Prototype

Input Page v1 Comp

Results Page v1 Comp

We nailed down a few key features in v1:

Highlighting “Winners”: We called out the bootcamps with the highest tuition, highest lost salary, and shortest length with assigned accent colors.

High Level Summary: We included a written “scorecard” in the top right to accompany the graphs and increase readability.

Limited Color Palette: For both aesthetic and usability reasons, we chose to combine a palette of grays, and an analogous palette of red and orange. This created harmonious visuals while still allowing us to highlight information.

From stakeholder feedback, we also identified further room for improvement for the next iteration:

  • The highlighting felt arbitrary.
  • There was no way for users to filter the results.
  • We needed to differentiate course length into part time and full time, as some bootcamps contain both.
  • Clarify how much salary was lost during the program, and how much was lost during the assumed job search time.
V2 Prototype

Input Page v2 Comp with specs

Results Page v2 Comp

Version 2 Edits Included:

Filtering: Users are now able to filter the information using four toggles for total cost, lost salary, tuition, and length.

Filtering toggles with specs

Overview Graph: We replaced the text-based summary with a “bird’s-eye view” graph. Now the user can immediately tell where on the list the highlighted bootcamps are, and compare the results without scrolling. This is most helpful for instances where the iframe is forced to be skinny and long.

Specs for the small “bird’s eye” graph

Breaking Down Data: As we mentioned before, we needed to display program length and lost salary in a more granular way. When users select the length or lost salary toggle, they see an expanded view of that information.

Lost salary data breakdown

Program length data breakdown

Embed Code: We needed an easy way for a user to embed the calculator, but wanted it to be a bit more refined than just using default browser pop-ups.

Embed and reset buttons

The embed code is revealed once the button is clicked.

Expanded Color Palette: We needed to accommodate the filtering by adding dark red and gold to our analogous palette. We also used the gold and orange to create a gradient to use in the input page and at the top and bottom of the results page.

Responsive Design: We made a pretty big deal about having a fluid layout in this post, so here are some shots of the calculator at various sizes.

Tablet Width Results Page Comp with specs

Mobile Width Input Page Comp with specs

Mobile Width Results Page Comp


Overall, it was an interesting challenge to bring new interpretation to a common tool, and to create such a flexible product.

Final True Cost Calculator landing page and results page

Engineering Challenges

From an engineering perspective, this was a pretty straightforward project. The Design Team did the heavy lifting by crafting an elegant way to present the data. We strove to mirror this quality in our code.

The backend was built on the same Ruby on Rails app that powers the rest of Bloc’s product. Its job was to consume the YAML file of bootcamp data assembled by our Growth Team, crunch some numbers, and render the information in an HTML document. The first pass of this part of the project resulted in some messy, logic-dense views, so we decided to refactor using the presenter pattern, largely inspired by this great blog post. Because we were presenting some tabular data, we made the somewhat controversial decision to use HTML tables. This approach worked great and probably saved dozens of lines of CSS.

def get_sorted_bootcamps(location, salary, true_cost_data)  
    salary = salary.gsub(/[$,]/, '').to_f

    bootcamps = true_cost_data[:in_person_bootcamps][location] +

    bootcamps = do |bootcamp|
      bootcamp[:lost_salary_program] = 0
      bootcamp[:lost_salary_job_search] = 0
      bootcamp[:lost_salary] = 0
      bootcamp[:true_cost] = bootcamp[:tuition]

      if bootcamp[:is_full_time]
        lost_salary_program = salary * (bootcamp[:weeks].weeks / 1.year)
        lost_salary_job_search = salary * (3.months / 1.year)
        lost_salary = lost_salary_program + lost_salary_job_search

        bootcamp[:lost_salary_program] = lost_salary_program
        bootcamp[:lost_salary_job_search] = lost_salary_job_search
        bootcamp[:lost_salary] = lost_salary
        bootcamp[:true_cost] += lost_salary


    bootcamps.sort_by { |bootcamp| bootcamp[:true_cost] }


-# Locals: bootcamps, attribute, selected_attribute{ class: selectable_attribute_class(attribute, selected_attribute) }
    - present(bootcamps, BootcampsPresenter, attribute) do |presenter|
      - presenter.bootcamps.each_with_index do |bootcamp, i|
        %tr{ class: presenter.highlight_class(bootcamp) }
          %td.small-label.y-axis #{ i + 1 }
          %td.graph{ colspan: 5 }
            .bar{ style: presenter.bar_graph_style(bootcamp, attribute) }
          - interval = presenter.highest_amount / 5.0
          - 5.times do |i|
            %td.small-label.x-axis #{ presenter.format_amount(interval * (i + 1), attribute) }

A peek at our use of the presenter pattern.

Once the backend hands the document off to your browser, it gets dressed up with a little Javascript and a lot of CSS. Our interaction requirements were such that we could get by using only the 33 KB of Javascript library luxury afforded by jQuery. Honestly, we probably could have even done without that. Our CSS made extensive use of the new hotness that is the Flexbox Layout. Things that were nearly impossible just a few years ago (like vertically centering variable height containers or consistently aligning multiple columns) were a breeze with Flexbox and worked well across modern browsers.

try {  
    // Set the height of the iframe to the document min-height.
    var $iframe = $(window.frameElement);
    var bodyMinHeight = parseInt($('body').css('min-height'), 10);

  } catch (e) {
    // We're embedded in someone else's page. ¯\_(ツ)_/¯

Living in an iframe means there are some things you can only do at home.

display: flex  

End 10 years of struggle using this one weird trick!

The nice thing about a project with minimal technical requirements is that you get some extra time to sweat the details, and, at Bloc, we love to sweat the details. When we launched the calculator, we were confident that folks would have a great experience regardless of browser or device because we had resized, flipped, pinched, and tapped to our hearts’ content.

We Plan To Make Improvements To The Calculator
  • We’ve already received requests to include other cities. This could be an interesting addition as we identify cities with a meaningful number of bootcamps from which a student can choose.

  • Expand the calculator to include bootcamps that cater to different goals for students. Example: Bootcamps that focus on beginners who simply want to “dip their toes” into coding, and not necessarily start a new career.

  • Explore other options for data visualization; bar charts are common, but there may be superior visualizations that simplify the way the data is displayed.

Two of Bloc’s major tenets drove the creation of this tool: taking pride in the craftsmanship of things we build and being an honest broker of coding bootcamp information. We hope that the True Cost Calculator makes the coding bootcamp selection process a little more enjoyable and informed.