As part of an effort to increase engagement in the then Guitareo application, we launched Guitar Quest—a gamified approach to learning electric guitar featuring musician and influencer Rob Scallon.
I was responsible for both the marketing and platform experiences. A key feature of Guitar Quest was an interactive SVG map, used across both the marketing site and platform, to visually represent lesson "levels" where difficulty increased as students progressed. To improve performance on the marketing site, I introduced Alpine.js, a lightweight (10 kB gzipped) JavaScript framework with Vue.js-like syntax, which enhanced loading speeds.
For the platform experience, I developed new components on top of our existing Vue.js component library, Vuesora, and ensured seamless data flow from our Laravel controllers to the templates. I also introduced Tailwind CSS to streamline styling and establish a scalable convention for future development.

Before we built Musora’s unified platform, Musora operated as four separate brand applications— Drumeo, Pianote, Guitareo, and Singeo. This fragmented structure created technical challenges when delivering new features and limited students to a single brand and instrument per membership.
Previously, we maintained three separate internal libraries for shared code: Bladesora (Blade templates), Vuesora (Vue components), and Stylesora (Tailwind CSS utilities, which I created). Deploying a new feature often required updates across seven different GitHub repositories, slowing down development.

To streamline operations and improve the student experience, we embarked on an ambitious unification project. I initiated the process by setting up our web and mobile GitHub repositories and ensuring all necessary technologies were installed. I then migrated our shared libraries into the unified platform repository and led the development of a global app redesign. This included a new navigation system, a cohesive site wrapper, and visual updates to support both light and dark modes.
By consolidating our platform, we significantly accelerated development and enabled students to access all instruments and brands under a single membership, greatly increasing the value of their subscription.

As part of the new unified Musora platform, I also decoupled the marketing front-end environment from the main platform. This separation allowed the marketing team to use their preferred tools without causing unintended side effects on the platform, and vice versa. I achieved this by using separate Laravel Mix configurations, ensuring that each environment had its own optimized build process. This enabled the marketing team to leverage lightweight libraries like Alpine.js, improving performance and SEO without impacting the main application.

In the legacy platforms, students could only bookmark content into a single collection called "My List." With the launch of the unified Musora platform, we wanted to enhance this functionality by allowing students to organize all content—Songs, Lessons, and Exercises—into individual playlists. Taking inspiration from Spotify, we introduced features enabling users to edit playlist names, reorder items via drag-and-drop, update thumbnails, and more. Additionally, students could pin up to five playlists to the main sidebar for quick access.

I led the front-end development of these new features, creating the Playlist index page with drag-and-drop sorting and implementing the pin functionality for the sidebar. To manage playlist state across multiple Vue components, I introduced Pinia, ensuring efficient data sharing across the application. I also updated the playback page experience to support multiple content types.

In addition, I supervised and mentored another front-end developer in building the "Create Playlist" modal, which needed to be integrated across all content types. Unlike Spotify, our platform had the unique challenge of handling content with child items, requiring careful UI considerations to allow students to decide whether to include child content in their playlists.

The goal of this feature was to offer short-form workout content as an alternative to our traditional multi-lesson learning structure. Leveraging the third-party practice tool Soundslice, we combined video lessons with interactive sheet music to enhance the learning experience.

I developed a component that segments the video into individual chapters, allowing students to quickly navigate to specific sections. Each chapter card provides two options: jump directly to that point in the video or open the Soundslice player to loop and practice along with sheet music in real time. To optimize the user experience, I utilized Soundslice's API to customize the player’s behavior, ensuring it met our specific learning needs.

Early in my time at Musora, I aimed to improve the onboarding process by creating documentation for our frontend libraries: Bladesora for HTML templates, Vuesora for Vue components, and Stylesora for custom Tailwind classes.

To achieve this, I used VuePress to generate a documentation site, which I then deployed to Netlify. VuePress made it easy for developers to reference core frontend components and copy/paste code snippets directly into their projects, streamlining development and onboarding.

I built a Tailwind utility class library called Stylesora to centralize Musora's custom styles. Working closely with the UX team, I ensured all Figma designs were accurately reflected in the front-end implementation. By using CSS as JSON, I seamlessly integrated Stylesora into our Tailwind config, making it easy to maintain and scale our design system.

The team aimed to migrate our MySQL database and existing Musora CMS to Sanity CMS. This transition required a fundamental shift in how our front-end components received data. Instead of passing data from Laravel controllers to templates and then to Vue components as props, we needed the components themselves to fetch data directly from Sanity.

I led the front-end team in refactoring our Blade templates, replacing multiple HTML partials with single-page Vue components. Each page component now retrieves its own data and passes it to child components, enabling a more modular and scalable architecture. To improve the user experience, we introduced skeleton loaders across the site, which are triggered onBeforeMount while awaiting data from Sanity.

Another key challenge was ensuring both mobile and web front-end teams stayed aligned during this large-scale migration. Since GROQ queries can be complex, and not all developers were experienced in writing them, I created an NPM package called Musora Content Services (MCS). This package provided standardized functions for both mobile and web teams to retrieve content data from Sanity.

To maintain reliability, we implemented Jest tests for all GROQ queries, ensuring they worked correctly with every update. These tests were integrated into GitHub Actions to run automatically on every push to main. We also expanded the package to include user-specific endpoints from our own API, making it the central gateway for all data requests in our web and mobile applications.

To improve the developer experience, I created documentation using JSDoc, a tool that generates API documentation from properly formatted JavaScript comments. By simply ensuring that all new functions and classes were commented, developers could run a build command to generate updated documentation automatically. I documented the process in the README file and published the docs to the web using GitHub Pages.

Additionally, I set up a symlink from the Musora Content Services repository to our Musora Web Platform repository. This allowed developers to test changes to the MCS package directly within the web platform—without needing to push, publish, and reinstall every iteration. This significantly reduced friction in development and sped up the feedback loop.

This migration not only improved development efficiency but also laid the groundwork for decoupling the web application from the back-end. By shifting toward a fully front-end-driven architecture, we enabled the possibility of deploying static files instead of relying on Laravel to generate HTML, ultimately reducing infrastructure costs and improving performance.

I spent four action-packed years at Musora and held three different titles. I did everything from managing staff to creating workflows in Jira to building experiences from the ground up. Here are some of my takeaways, both technical and personal.

Lesson One: The Necessary Evil of Frameworks in Large Teams.

I enjoy writing my own code. I don't like relying on third-party libraries and frameworks—for many reasons.

That said, they have their advantages (whether I like it or not). Libraries and frameworks set conventions. When I'm creating a library or package, I want it to be well-structured, readable, and documented with human-friendly naming conventions. But very rarely do we get the time to do this.

When you use a library like Vue.js or Tailwind CSS, these conventions are already established, tested, and backed by a community. I can tell my devs, "Read the documentation," and trust that they'll find what they need. That’s far more efficient than teaching them the "Miguel way" of doing things.

It also helps with onboarding. If a new developer already knows these technologies, they can start contributing right away instead of learning our custom-built solutions.

Lesson Two: Working with iFrames is a pain.

Most of my work at Musora followed a familiar pattern—create components, fetch data, build new routes, repeat. But every so often, I had to work with a third-party package rendered as an iFrame.

Out of consideration, I won’t name the package, but it was a core feature of the Musora platform. Because of that, marketers and project managers frequently requested updates and customizations.

Here’s the problem: iFrames, like web workers, are completely encapsulated. You can’t manipulate them from the outside unless they expose a way to send and receive messages. Events won’t work because they bubble (or propagate) to the parent, and the iFrame can’t capture events from the parent.

And don’t even think about targeting elements inside an iFrame from the outside—that violates the browser’s Same-Origin Policy.

In a perfect world, iFrame-based packages would expose all the necessary options to update the UI and listen for changes. But we don’t live in a perfect world. If the iFrame’s owner doesn’t add your domain to the CORS headers, you have no way to modify it. You have to work with what you're given.

When all else fails, build it yourself.

Lesson Three: Take Initiative—Don’t Wait for Things to Happen.

It’s easy to say, "It’s not my job," or "That person is out sick," or "Someone else was supposed to do it." But waiting for the ideal situation will only slow you down.

Instead, take ownership. Offer solutions.

If the UX manager is juggling multiple projects and the Figma designs lack error states—add them yourself. Even if they’re not perfect, at least they’ll exist.

If you're waiting on a back-end engineer for a solution, but you can offer a workaround—make that Plan A. Pitch it, implement it. Chances are, you’ll be making their life easier.

If a Jira ticket requires engineers from different teams, but you can do both jobs, don’t let others’ availability block progress.

My father always said, "Perfect is the enemy of good," and "A job worth doing is worth doing well enough." Essentially—get it done.

Of course, this mindset can lead to burnout—something I know all too well. Leadership often means doing more, taking responsibility, and stepping up when things stall. The upside? You’ll learn more and have more to show for your time at a company.

Lesson Four: Put People First.

If I can be blunt—don’t be an asshole. You won’t get the best performance, collaboration, or respect by treating people poorly.

Do the opposite. Go out of your way to acknowledge that nothing on the Project Roadmap gets done without people.

I won’t open the can of worms that is Generative AI, but even AI still needs humans—because people understand context. Even the lowest-performing team members can provide valuable insights into why something isn’t working. Listen to them. Make them feel appreciated.

Technology exists for people, not the other way around.

And this applies to yourself too. Your job, with all its arbitrary deadlines, is not more important than your health. You can’t do good work if you completely neglect yourself.

Ultimately, that’s what companies should want for their employees, even if they don’t say it enough. Maybe it’s worth reminding them once in a while.

Inspired by the Lego Art Series, I set out to build a web app for creating mosaic-style artwork similar to Lego’s Batman, Iron Man, and Beatles sets. The goal was to allow users to generate their own pixel art mosaics, visualize the grid layout, and receive step-by-step building instructions, including a list of required parts that could be purchased from Webrick.

Technical Approach

To achieve this, I used HTML Canvas to generate the artwork and store grid data, including the position and color of each "brick" (represented as 10px circles). Rather than relying on third-party JavaScript frameworks, I explored using native JavaScript custom elements to keep the project lightweight and modular.

For styling and performance, I chose TailwindCSS alongside Hugo as a static site generator. Although the app functions as a single-page application, Hugo provided useful tools for managing front-end assets, such as handling relative links in production.

Since frameworks like React and Vue offer built-in state management (e.g., Redux, Pinia), I implemented a custom event bus using the publish/subscribe pattern for component communication.

The application consists of three main experiences:

• Create – for mosaic creation
• Buy Parts – for generating a parts list
• Instructions – for guiding users through the building process

While the project remains a proof of concept, it successfully demonstrates that a complex front-end application can be built using JavaScript custom elements without relying on a framework. There are still areas for optimization, but I’m happy with the outcome and the lessons learned.

The Create step consists of three parts: the HTML canvas for creating the mosaic, the left sidebar for each step of the process, and the view window itself. I built custom elements for the canvas, steps 1-4 of the creation process, and finally, the index.js file to house all of these elements. The index also contained the code for the view window. Let's discuss each part in more detail.

Rendering the Mosaic Grid

This was by far the most complicated part of the project. The core logic for rendering the mosaic grid lies in the drawGrid() function. This function is responsible for initializing the blank state of the canvas and is called when a user resets their project or changes the canvas size.

The function first applies two guard clauses: one to ensure the drawing context exists and another to prevent errors when an invalid canvasWidth is provided. It then retrieves the grid configuration from GRID_CONFIG, which determines the grid size (rows and columns) and dimensions (width and height). These values are passed into setGridSize() and setCanvasDimensions(), ensuring the grid dynamically adjusts when resized.

The actual drawing process begins by calculating the radius of each circle based on the grid size. The function sets the global composite operation to destination-over to ensure new elements are drawn beneath existing content. Then, it initializes an array, this.circles, which stores the position, fill color, and stroke color of each circle in the grid.

Using a nested loop, drawGrid() iterates over each row and column, calculating the X and Y coordinates for every circle. It then uses the arc() method to draw each circle on the canvas. These circles represent the Lego studs in the mosaic. Finally, each circle's properties (position, fill, and stroke color) are stored in this.circles for reference when rendering updates.

Mosaic Creation Steps

The mosaic creation process consists of four steps, with Step One focused on setting up the canvas. Here, we choose the canvas size, background color, and frame color. Each step includes HTML inputs that dispatch events, which are handled by index.js. This file updates child components like _canvas.js by modifying attributes on the MosaicCanvas custom element. These attributes trigger updates to the UI using the attributeChangedCallback lifecycle method.

Step Two introduces image uploading. The uploaded image is received by the MosaicCanvas component and drawn onto a secondary canvas. This project uses two canvas elements: one for the mosaic grid and another for the reference image. I also add an SVG overlay of the grid to help the user visualize what the converted image will look like. When an image is uploaded, an updateImage event is dispatched, updating the image attribute and triggering the draw() method, which redraws the imageCanvas. After editing the image with available tools, we convert it into a mosaic using the convert() function.

The convert() function performs two key tasks:

• It iterates over the mosaic grid (an array of objects with set x and y coordinates) and extracts the primary color at each point using the calculateResult() function, which retrieves pixel data via Canvas’s getImageData() method.
• The extracted color is compared to LEGO’s color palette using the compareColors() function. This finds the closest match and updates the this.circles array, storing the new color values.

Finally, the drawCircles() function renders the updated color data onto the mosaic canvas, while the image canvas is hidden.

Step Three enables further editing. Users can modify colors in groups or adjust individual circles by detecting the closest grid coordinate to a mouse click. Like previous steps, updates are triggered through dispatched events that the canvas elements receive.

In the final step, clicking “Finish” completes the mosaic. This action unlocks additional options, including Instructions and Buy Parts, allowing users to finalize their creation.

View Window

The view window houses both the step controls and the project itself. It is designed to enhance the user experience by allowing zoom functionality, making it easier to edit individual circles on the grid.

The window has two main features: the zoom slider and the image toggle. The image toggle is a simple checkbox that shows or hides the imageCanvas, allowing users to compare their mosaic with the original image while editing.

The zoom slider adjusts the canvas size by applying a transform: scale() value via CSS on the mosaicCanvas element. Since the parent container has overflow: auto, users can scroll to navigate the enlarged canvas as they zoom in.

The Buy Parts step processes the parts data from the previous step, listing each part, its quantity, and relevant metadata such as Webrick part IDs, color codes, prices, and images. This metadata is stored locally in a JSON file.

In index.js, I iterate through the saved parts data, cross-matching it with the stored JSON file. If a color code matches, I merge additional part details into the existing dataset. This enriched data is then used to generate the UI, including a sidebar that calculates total costs for purchasing parts individually from both Webrick and LEGO. To do this, I extract unique color codes, count their occurrences, and multiply them by their respective prices, storing the results in a structured object.

<INVENTORY>
    ${ this.parts.map(item => `
    <ITEM>
        <ITEMTYPE>P</ITEMTYPE>
        <ITEMID>${item.id.bricklink}</ITEMID>
        <COLOR>${item.id.color_id}</COLOR>
        <MINQTY>${item.quantity}</MINQTY>
    </ITEM>`).join('')}
</INVENTORY>

Users can also download the parts data as an XML file, which Webrick supports for direct cart uploads. To achieve this, I use JavaScript template literals to map the parts data into XML format. The XML file is then generated as a Blob URL, allowing users to download and upload it to the Webrick Parts Tool for easy purchasing.

The final step, Instructions, closely follows LEGO's instruction format. The process begins with an introduction page comparing the finished artwork to the original image, followed by step-by-step assembly instructions.

To achieve this, I divided the mosaic into smaller 16x16 grids, numbering each item and providing a legend of unique colors. This ensures users don’t have to distinguish between similar shades. The legend assigns a number to each color, while the right-hand grid displays the corresponding mosaic section.

This required multiple HTML <canvas> elements. I processed the full parts data to create a structured dataset representing the 16x16 grids. The initializeBrickData function calculates the number of subgrids needed along the X and Y axes, storing the results in a gridArray. Then, two functions handle rendering:

• printPages: Generates the necessary HTML for each instruction page. A 48x48 grid, for example, results in 9 instruction pages.
• printBoards: Draws each subgrid onto its corresponding canvas, targeting the elements using the art-board="{i + 1}" attribute.

Each section follows an overview page showing the mosaic portion being worked on. Users progress through each subsection until the entire mosaic is complete. The final step renders the finished mosaic, simulating artwork hanging on a wall.

This project came with many challenges, and there are aspects I’d like to revisit and improve. However, I'm pleased with the core experience and look forward to refining it further.

Wow, while the experiment of building a complex front-end application with JavaScript Custom Elements was ultimately a success, I definitely learned a lot about how they work under the hood.

Lesson One - It's possible.

Let's start with the positive: It's possible. You can build an application with Custom Elements. You can use them to break your site’s structure into modules—headers, navs, footers, etc. You can pass data to them using internal properties or attributes. They do almost everything that Vue and React components can do, but with less tooling. Vanilla JS Custom Elements are more performant than using a virtual DOM to re-render the front end, especially when you don't need to update multiple components at a time.

Lesson Two - It's simpler, in some ways.

This one is a bit more subjective, but I wanted to include it regardless. There's something about building Custom Elements that feels closer to the bone than using a third-party framework or library. You know exactly what you're building, and you're only building what's necessary. While it may be simpler to spin up a new Vue or React project, especially if you're experienced with these tools, it comes at a cost—vendor lock-in is one. Major version updates can introduce breaking changes. And let's not forget the endless node_modules dependencies.

Lesson Three - You'll miss reactivity.

You’ll miss reactivity. The ability to update a value and have multiple components re-render is kind of a beautiful thing. Everyone has had that experience of "Oh... it just works!" that a virtual DOM and partial re-renders provide. If you want multiple elements in your application to update at once, you only have so many options. I used a pub/sub pattern and created an event dispatcher, but you have to manually tell components to listen for specific events and update accordingly. I also experimented with a state machine and even considered using a web worker to manage application state. But no matter what, you still have to worry about manually re-rendering components when the state changes. Granted, this could be considered a "feature, not a bug" of working with Custom Elements. And the fact that you're only building what you need is still a plus.

Lesson Four - You can't have your CSS cake and eat it too.

If you use the Shadow DOM in your Custom Elements, they won't inherit your global CSS. So say goodbye to using your favorite CSS framework globally. The Shadow DOM provides encapsulation, which is great for sharing components between projects without worrying about restyling them or dealing with unintended side effects from global styles. However, this also breaks the convention of separating concerns. If you have similar styles shared between multiple components, you’ll have to rewrite them repeatedly.

There is one exception: CSS Custom Properties (aka CSS variables) do inherit through the Shadow DOM. Additionally, there's a somewhat hacky workaround where you can import an external CSS stylesheet into your component. That said, you can always create your component without using the Shadow DOM, but that comes with its own trade-offs: lack of encapsulation, leaky CSS, and possible conflicts when using document.querySelector. Like everything in software engineering, there are always trade-offs.

Lesson Five - I wish we had back-end rendering.

A lot of what I was rendering didn’t need to be dynamically updated. How much of this would have been solved with native HTML partials (if they existed)? If we had built-in HTML partials, I’d argue that many static site generators (SSGs) would be unnecessary. Yes, there are many tools that attempt to solve this problem (including 11ty), but there is no native, out-of-the-box solution. You're still creating multiple JS files and either bundling them or importing them into an index.js and including it in your page. If the user disables JavaScript... there goes your application.

For interactive components that manage their own state, yes, we need JavaScript, and we always will. But for presentational components that exist just to structure layout, I wish we could somehow render them as native HTML. Of course, this goes against the unfortunate norm of the web: "build everything in JavaScript React."

Lesson Six - Would I do it again? YES.

I believe the benefits outweigh the costs. My JavaScript Custom Element will outlive your Svelte, Vue, React, Ember, Angular, etc., component. When I'm building a new component, I know what I'm writing. I know how it works. It’s part of the core language. Also, no compilation time—Custom Elements work out of the box. If you want to use a module bundler and tree-shaker, go right ahead... but it's not required.

They can be used with any framework. And I have a feeling that the language will evolve and browsers will start supporting new features that mimic some of the best parts of modern frameworks—without the headaches. I've seen it happen time and time again.

Forming the Idea

I wanted to create a faster, simpler, and cheaper way to develop and deploy sites for small businesses. I wanted to avoid the headache of developing and maintaining Wordpress sites. Scaling this into a viable business was my first goal, but my second goal was to experiment with JAMstack technologies and see exactly what was possible. I wanted to "productize" web services. The main product being website development. Other services I wanted to offer were:

• Web Design
• Brand Strategy
• Digital Marketing
• Site Audits

Web Design would be provided by the ManyPixels design agency. I leaned on my own professional experience to provide Brand Strategy and Site Audits. The idea was to work with clients to identify the goal of their existing site or brand and provide advice on how to best communicate that to their customers. For all design updates to their existing brand or site, I would lean on ManyPixels.

Digital Marketing involved providing a social media content strategy and a paid ad strategy, with the help of my better half, Celeste Fondeur, who has professional experience as a content writer and social media strategist.

How Tech Informed Pricing

The goal of the pricing strategy was to market for volume. With a lower price point, I would be able to gain more clients. The turnaround time would be much faster given the simpler tech stack. I would utilize ManyPixels to create templates that would fit most small business needs.

I would upsell based on the number of revisions, which I priced as "Site Monitoring." If the customer wanted something completely custom-built, the price was determined after a conversation with them. This could include, and in fact did, working with customers who had completely different tech stacks and tech needs.

Choosing the JAMStack

The JAMstack (JavaScript, APIs, and Markdown) is a modern web architecture commonly used with static site generators like Hugo and 11ty. These tools convert Markdown files into HTML at build time, eliminating the need for a server-side language like PHP. This approach allows for reusable templates and a highly efficient deployment process.

To deploy these sites, I simply pushed each project to a dedicated GitHub repository and connected it to Netlify. With minimal setup, any updates pushed to GitHub would trigger an automatic build and deployment.

Netlify also provided a Git-based CMS, originally called Netlify CMS (now Decap CMS). Unlike traditional databases, Decap CMS stores content directly in a Git repository, making it a lightweight solution perfect for small business marketing sites.

To enhance the CMS experience, I built custom React components for the preview window, ensuring a 1:1 representation of the final website. This approach eliminated the need for paid hosting, as there was no PHP backend to maintain. Any additional functionality—such as social media feeds or event calendars—was handled through third-party APIs.

I chose Hugo as the static site generator due to its blazing-fast build times. I also created multiple pre-built templates tailored to different business needs. The end result was a highly adaptable system that provided small businesses with cost-effective, low-maintenance websites requiring minimal configuration.

Next, I'll dive into the technical details behind the CMS and custom templates, followed by key lessons learned from building Block Digital.

The CMS Config

Netlify CMS relies on a config.yml file to define its behavior, specifying where content is stored, how collections are structured, and how the editing interface is configured. The core of this setup revolves around collections and fields, which determine what content can be edited and the specific fields available for each type of content.

Each field is defined by a widget property, which determines the type of input used. Some common widgets include:

• string – Basic text input
• boolean – A simple true/false toggle
• image – File upload for images
• list – A repeatable set of items
• object – A container for grouping multiple fields

The object widget is especially powerful because it allows nesting multiple widgets under a single field. You can even nest other object widgets, making it ideal for structured content.

Structuring Pages and Components

I structured each page of the website as a collection and used appropriate field widgets to build out the content. The key to flexibility was leveraging list and object fields to create nested components and multi-column layouts.

To enable this, I added a list field called components. Each component within this list was an object containing elements such as:

• Buttons
• Content (Rich Text / Markdown)
• Images
• Forms

For more complex layouts, I introduced "nested columns," which allowed additional components inside them. This created a flexible system where users could build intricate layouts directly from the CMS.

Custom Attributes and Styling

To allow users to customize styles and attributes, I added a list widget called attributes to most elements. This let users define custom attributes and values as needed.

Additionally, column elements accepted a string of class names, making it easy to apply custom styles—such as defining column widths in a CSS grid system.

Creating the CMS Interface

The CMS interface itself required a dedicated HTML file at /static/admin/index.html, which acted as a single-page application (SPA). Netlify CMS provided an option to extend the interface with custom React components, making it possible to preview content inside the CMS.

Inside the static/admin/previews/ directory, I created preview components for the blog and general page layouts. Then, in a preview.js file, I registered them with the CMS:

//Import Previews
import SitePagePreview from "./SitePagePreview.js";
import BlogPagePreview from "./BlogPagePreview.js";
import HeaderPreview from "./HeaderPreview.js";
import NavigationPreview from "./NavigationPreview.js";
import FooterPreview from "./FooterPreview.js";
import SettingsPreview from "./SettingsPreview.js";

//Preview Style
CMS.registerPreviewStyle("../../css/style.css");

//Preview Pages
CMS.registerPreviewTemplate("site", SitePagePreview);
CMS.registerPreviewTemplate("blog", BlogPagePreview);
CMS.registerPreviewTemplate("footer", HeaderPreview);
CMS.registerPreviewTemplate("navigation", NavigationPreview);
CMS.registerPreviewTemplate("footer", FooterPreview);
CMS.registerPreviewTemplate("settings", SettingsPreview);

This approach ensured that the preview inside the CMS closely matched the live website. The site's assets, including JavaScript bundles and minified CSS, were handled with Gulp.js for optimization. (Today, alternative tools like Vite or esbuild provide more modern asset bundling solutions.)

While this CMS setup successfully met my goals, it also introduced some challenges—such as styling limitations and CMS-specific quirks—which I'll discuss in the Lessons Learned section.

Configuring Markdown Files

Like many static site generators (SSGs), Hugo uses markdown files in combination with layout templates to generate pages. The markdown files store content and metadata, while layout files determine how the content is displayed. The front matter in a markdown file specifies which layout should be used.

Typically, there is a list layout for blogs and a single layout for individual pages. Sections, columns, components, and attributes are defined in the markdown content in the same way they are structured in the CMS configuration. At build time, Hugo parses the markdown metadata, selects the appropriate template, and renders the final page.

Converting Markdown to HTML

Inside these templates, you can include logic to iterate through the markdown data. Since Hugo’s front matter supports structured data formats like YAML, you can define arrays and objects, making them accessible within the template.

Once I ensured that the markdown structure in my content file matched the Netlify CMS config.yml file, it was just a matter of rendering the appropriate HTML. For both the single.html and the list.html files within layouts/_default/, I iterated through the markdown data structure specified in each content file. The template itself checks to see if a section or component exists, then builds the HTML accordingly.

This ensured that any updates made in the CMS editor were reflected in the generated site. In essence, the entire site structure existed as data—so all we were doing was manipulating data to render HTML.

Building The Templates

Building the templates themselves was straightforward. Once the structure was in place, I could create almost any layout. Since I was working solo, I didn't have a dedicated UX designer, so I partnered with an external agency, ManyPixels.

They designed six flexible layouts that could be adapted to fit various businesses—including the design for the Block Digital website. Once the designs were complete, I handled the development, ensuring that all websites were fully responsive and accessible on all devices. The image above showcases the 'StoreFront' layout, designed to be suitable for most small businesses.

Adding a Style Guide

Lastly, I wanted to include a style guide with each website. Why? If a client ever wanted to modify the layout of their site—not just the content—I wanted them to have a reference.

The style guide showcased all available components, such as form elements and buttons, along with guidelines on typography, colors, and accessibility best practices (including ADA compliance).

By incorporating these guidelines, I ensured that clients had full control over their site's visual identity while maintaining consistency and usability. Best case scenario.

Block Digital was a fun and ambitious project, but ultimately, it was not sustainable. It served as a tech demo showcasing what was possible with this stack. I learned that you could mimic a traditional CMS—including live previews—using Netlify and the JAMstack. These technologies saved time and money, but as I quickly realized, good technology alone does not make a successful business.

Lesson One: Good Tech ≠ Good User Experience.

While Netlify CMS provided a powerful way to structure content using nested fields, the user experience was far from ideal. Users had to navigate deeply nested dropdowns to find the fields they needed, making content management cumbersome. This was less a limitation of Netlify itself and more a result of my design choices. In hindsight, I wish there had been a more intuitive way to visualize nested fields—perhaps something Decap CMS has improved upon.

Lesson Two: The Difference Between a Service and a Product is TIME.

My original goal as a business owner was to create a tech stack so simple that I could customize and deploy a website within three days—just add the company name, upload assets, update copy, and launch. In reality, clients often require multiple revisions. During my time as a Sr. Frontend Developer at Union.co, a high-end digital marketing agency in Charlotte, NC, I learned about the AOR ("Agency of Record") model, where agencies keep clients on retainer. This approach allows clients a set number of revisions while ensuring the agency's time and resources are used efficiently. If I had adopted a similar model, it could have helped balance client needs with sustainable business practices.

Lesson Three: Simplicity is Subjective.

What seems simple to a developer—nested columns, attributes, and components—may not be simple to a client. Many clients were already familiar with widely used platforms like WordPress or newer solutions like Squarespace. Introducing an alternative CMS, even if technically superior or more cost-effective, often added complexity rather than solving a problem for them. One client asked if I built Squarespace templates, another asked if I used WordPress, and one required WordPress due to their business needs. This experience led me to my next realization...

Lesson Four: Maybe You Shouldn't Reinvent the Wheel.

Just because you can build something doesn’t mean you should. If the business goal is to create websites quickly, it's essential to research all available technologies before reinventing the wheel. Ironically, my highest-paying client required me to build and update WordPress templates instead of using a custom solution. It spoke volumes that a larger agency like Union.co also relied on WordPress, alongside other PHP-based CMSs like Craft. Ultimately, the best choice is the one that aligns with both your business goals and your clients' needs. Overengineering can be a costly mistake.

As the team's Frontend UI Engineer, I was responsible for translating our lead designer’s Zeplin specs into a functional web experience. I built every feature of the site using CSS3, jQuery, and Django templates.

I joined during what they considered Knozen 4.0. The Team had gone through 3 major rereleases up until that point, with the original being to use personality charts to find the right job applicants and vice versa. When I joined, the team had just finished porting the Knozen native mobile app to the web. The app used Facebook authentication for logging in and was primarily marketed to Facebook users—a strategy that proved highly effective. Once the web app launched, engagement grew exponentially.

To capitalize on this momentum, the team worked rapidly to develop new features that would add value and keep users engaged beyond completing the Knozen quiz and generating their personality chart. However, transitioning to the web also introduced unique challenges, as web applications have limitations that native apps do not.

In the next section, I'll discuss these challenges and the solutions I implemented to overcome them.

The site featured a wide range of colors, animations, and fixed elements—more than I had ever seen rendered on a single web page. The Knozen quiz itself had an infinitely scrolling background with dynamic feedback animations that indicated which traits increased or decreased based on user responses. Additionally, the background color changed with each question, and the user's personality chart updated in real time.

The personality chart alone featured at least 24 different colors, along with numerous other color variations throughout the site. All of this put a significant strain on performance, especially on mobile devices—where most of our traffic came from. In my mind, a mobile web app should function just as smoothly as a native app, so I set out to optimize performance.

To minimize browser repainting issues, I used GPU-friendly CSS and ensured all animations were hardware-accelerated. Where appropriate, I applied transform: translateZ(0); to trigger GPU acceleration instead of relying on the browser’s default rendering. Additionally, the combination of animations, a fixed navigation bar, and overflow-scroll on the wrapper caused noticeable stuttering during scrolling on mobile devices. I resolved this by applying -webkit-overflow-scrolling: touch;.

To debug the mobile experience without relying on tools like BrowserStack (I hate BrowserStack), I connected my iPhone directly to my MacBook. Using Safari Technology Preview, I was able to open an inspector window on my Mac that pointed to a webpage running in my mobile Safari browser.

The end result was a much smoother, more performant mobile web app that closely mimicked the responsiveness of a native application.

As I mentioned earlier, I was brought in to help add new features that would increase engagement while building on the success of the core feature, the Knozen Quiz. One of these new features was "Feelings."

We noticed that users frequently revisited their profiles and reshared their personality charts with friends. To build on this behavior, we introduced a way for users to share how they were feeling at any given time.

The feature allowed users to select an emoji from a modal within their profile. Once chosen, the emoji would appear on their public profile for friends to see. The UI consisted of:

• A large emoji representing the user's current mood.
• An infinite scrolling background of other emojis, reinforcing the idea that it was one of many options.
• A subtle fade-in/out animation on profile images to display the emoji dynamically.

The infinite scrolling effect was achieved using CSS keyframes, while the emoji fade-in/out was handled with CSS animations. The end result was a lightweight, engaging feature that seamlessly fit into the existing Knozen experience.

The last feature we launched was Themed Quizzes. Building on the popularity of the Knozen Quiz, we made a bet that the most engaging part of the app was taking quizzes.

We developed multiple themed quizzes, such as:

• Are You a Cat?
• Are You a Rebel?
• Are You Wild at Heart?

The quiz UI featured a carousel positioned beneath the user's Knozen chart. Users could scroll or click through the carousel to browse available quizzes. Selecting a quiz card would initialize a new quiz session.

Upon completion, players were rewarded with a fun GIF animation or meme. Towards the end of the project, I also took on the responsibility of creating and editing these images in Photoshop.

Quiz results were displayed on both the user's profile and their friends' profiles, allowing them to see how compatible they were.

I enjoyed my time at Knozen and I'm grateful to the team for the opportunity. I also learned valuable lessons on both the technical and business sides.

Lesson One - Optimize for Mobile.

Today, the term "Mobile First" is ubiquitous among designers and developers. Back in 2016, however, many web developers still prioritized desktop, with mobile as an afterthought.

The problem? Desktop computers are far more powerful than mobile phones. A smooth experience on your desktop might be completely broken on mobile. Test on mobile early and often!

Lesson Two - Analytics Matter.

With Facebook and Google Analytics, we could see where our traffic was coming from, user demographics, and which devices were most popular.

This data directly influenced our feature prioritization and played a crucial role in optimizing for mobile users.

Lesson Three - New Features ≠ Success.

We worked hard, and after launching Knozen 4.0, traffic spiked—only to drop soon after. In marketing terms, it wasn’t “sticky.”

I once heard, "You have to throw things at a wall and see what sticks." At the time, I resented that approach—it felt thoughtless. But in hindsight, there was wisdom in it.

You can’t predict which features will succeed. Even if you pour your heart and soul into an idea, your users determine its success or failure. In our case, I believe our audience was primarily younger individuals who enjoyed quick, fun iPhone games.

As the team's UX Developer, I was responsible for translating Photoshop design documents into a fully functional web application using HTML/Handlebars, CSS/Sass, and JavaScript/Ember.js. This included implementing all UI elements, interactions, and the responsive grid system.

We collaborated with a talented Brooklyn-based design agency, Milkshake, who designed the UI for Simply360. We held regular review meetings to discuss new features, requirements, and any design or development constraints. Once the initial designs were complete, they were handed over to us for implementation.

Using Ember.js

We built the application using Ember.js, an MVC JavaScript framework developed by the team behind Ruby on Rails. Ember.js had its own ecosystem and CLI tools for creating and managing components:

ember generate component my-component-name

For our asset pipeline, we used Broccoli, which is comparable to Grunt or Gulp but optimized for fast incremental rebuilds.

Styling with Sass & SMACSS

For styling, I used Sass due to its ability to define variables, nest styles, and easily import other files. I followed the SMACSS methodology, ensuring that my "modules" aligned 1:1 with Ember components. This made it simple to organize and locate styles while maintaining a clear CSS hierarchy:

• Base Styles
• Layout Styles
• Component (Module) Styles
• State Styles

Templating with Handlebars

Ember components consisted of a JavaScript file for interactions and a .hbs (Handlebars) file for HTML structure. Ember used Handlebars as a templating language, making it easy to inject dynamic content into the UI.

Creating a Native App Feel

The biggest motivation for using modern frameworks like Ember was to mimic the smooth experience of native applications while maintaining the accessibility of a web app. Unlike traditional multi-page applications that require hard reloads, Ember allowed for seamless page updates with client-side routing.

Beyond responsive design, I focused on interactions to make the app feel native, such as sidebar navigation animations. I achieved this using CSS transitions and transforms to create smooth motion effects.

Final Thoughts

Simply360 was an ambitious project, and we successfully launched an MVP for clients. I'm proud of the work we accomplished.

In the next section, I’ll share some of the lessons I learned.

Simply360 was my first opportunity after my time at the Startup Institute of NY. I learned a lot about working for a startup, building applications with modern tools, and collaborating within a small team. Here are some of my main takeaways.

Lesson One: Choose Your Technology Wisely.

At the time, we opted to use bleeding-edge technology, including Ember.js as our front-end framework, along with its CLI tool, Ember CLI, for creating new components. We also used Broccoli for asset management, along with other very new tools.

When adopting new technologies, there are inevitable challenges. One major issue we encountered was Ember injecting multiple <div> elements into the DOM after compilation. Not knowing exactly what would be rendered to the DOM made styling difficult, as CSS that relied on nested elements became unpredictable. To work around this, I had to add excessive class names, which polluted the template.

Another challenge of using new technology is the lack of developer support. Many times, we faced issues unique to our application that we couldn’t find answers for. At one point, our CTO even had to rewrite parts of the source code to accommodate our needs.

Lesson Two: Startups Are Not Regular Jobs.

As someone fresh into my web development career, I was excited for my first official job. During my time at the Startup Institute, I had gained experience by volunteering at several startups in New York, but this was different—this was my first time working in a non-linear environment.

Unlike a traditional 9-to-5 job, working at a startup often means racing toward deadlines. Working 50–60 hours a week was common, and while early-stage employees typically receive some equity, a startup’s survival is never guaranteed.

That being said, your efforts directly impact the health and success of the company. The high-pressure environment is demanding but also incredibly rewarding—not just financially, but in terms of experience. I learned to take pride in my work, knowing that my code and contributions were directly affecting users.

If you're early in your career, working at a startup—or even starting your own—is one of the fastest ways to grow.