Introduction
The Client
Solidigm is a U.S.-based subsidiary of SK hynix, formed in 2021 after SK hynix acquired Intel’s NAND and SSD business. Headquartered in Rancho Cordova, California, Solidigm has about 2,000 employees across 20 global locations. The team we worked with is responsible not only for SSD production, but also for managing employee accountability and ensuring consistent progress.
The Task
Our task was to design and develop an internal OKR (Objectives and Key Results) and task progress tracking platform tailored specifically for Solidigm’s unique organizational structure and workflows. Prior to this project, OKR tracking was managed manually using Excel spreadsheets — a method that was time-consuming, error-prone, and difficult to scale across teams. To address these inefficiencies, we were asked to build a robust, scalable application that could replace spreadsheets and bring structure, automation, and clarity to the process. The core goals of the project were:
- Eliminate the need for manual spreadsheet tracking
- Streamline and centralize OKR and task progress management
- Design a system that aligns with Solidigm’s internal hierarchy across teams, branches, and semesters
- Ensure scalability and usability across the entire organization
The Team
Timeframe
January 2025 — June 2025
Tools
Design — Figma
Development — .NET Core, Blazor, Azure SQL Server, Docker
Maintenance — Slack, GitHub, Notion, Azure
Design
Design System
Consolidating the existing design system on the Solidigm website was the first step of our design process. We recognized that aligning the internal tool with the company’s established visual identity would not only ensure a cohesive user experience but also reinforce a sense of professionalism and trust across the organization. By integrating familiar visual elements, such as color schemes, typography, and logo usage, we aimed to create a seamless bridge between public-facing platforms and internal tools.
A key focus was incorporating the Solidigm purple as the primary accent color throughout the application, maintaining consistency with the company’s digital presence. We also adopted the Sora typeface, which reflects a clean and modern aesthetic while supporting readability across various screen sizes and devices. Together, these elements serve as the visual backbone of the design system and were applied thoughtfully across navigation components, headers, buttons, and input forms.
Beyond aesthetics, this branding effort plays an important psychological role. By embedding the Solidigm logo and branding cues into the user interface, we aimed to encourage a stronger sense of identity, pride, and accountability among users. The result is a tool that feels like a natural extension of the Solidigm ecosystem: familiar, purpose-driven, and professional.
User Research
We met with the clients in person at the Solidigm office in Rancho Cordova to discuss their primary goals for the project. During this meeting, they shared valuable insights into their organizational structure, existing workflow processes, and the key pain points they hoped the new platform would address. Some of the core issues they highlighted included:
- Reliance on manual Excel spreadsheets for tracking OKRs and tasks
- Lack of consistency in how different teams reported and managed progress
- Difficulty in maintaining visibility across branches and semesters
- Limited scalability and inefficiencies in the current workflow
This conversation provided essential context that shaped our design direction and ensured our solution was closely aligned with Solidigm’s specific operational needs.
Competitive Analysis
To better understand the landscape of work organization tools and identify areas of improvement for our own internal platform, we conducted a competitive analysis of two well-established platforms: Asana and Monday.com. Our goal was to gain insight into how these tools structure task management, visualize progress, and support effective team collaboration at scale. This analysis helped inform both our product design choices and the direction of our feature set.
Asana stands out for its intuitive user experience and clean interface, especially in how it manages task hierarchies through tasks and subtasks. Its built-in collaboration tools, such as @ mentions and seamless integrations with third-party platforms, further enhance team productivity. However, we observed that Asana can feel overwhelming to new users due to its vast array of features, and it offers relatively limited customization options for the main dashboard.
Monday.com, on the other hand, excels in flexibility. Its highly customizable interface allows teams to tailor boards for a wide range of use cases beyond just task management, making it a versatile tool. That said, this flexibility can become a double-edged sword; users may find the lack of standard structure confusing, especially without clear guidance or templates to get started.
Both platforms revealed useful opportunities for improvement. Asana could benefit from offering more flexible dashboard customization and better onboarding to ease new users into its ecosystem. Monday.com has the potential to enhance usability by introducing industry-specific templates and streamlining the onboarding process to mitigate its steep learning curve.
We also identified potential threats for both tools: for Asana, the emergence of more visually dynamic and customizable platforms could challenge its market position. Monday.com, while powerful, risks losing users due to usability issues that arise when boards become overly complex without adequate structure or support.
These insights played a critical role in shaping our approach. By understanding where these leading platforms succeed and where they fall short, we were able to design a more focused and user-friendly solution tailored to Solidigm’s internal workflows and infrastructure.
Low-Fi’s/Mid-Fi’s
We began the low-fidelity stage by sketching out various features and user interfaces that could potentially shape the core of our internal task management platform. This initial phase allowed us to think freely and rapidly iterate on layout ideas, information structure, and overall user flow before committing to high-fidelity designs. Our goal during this stage was to focus on function over form: ensuring that the flow of information made sense and supported the user’s mental model for navigating OKRs, subgoals, and team hierarchies.
This hand-drawn sketch represents some of our earliest ideation work. We explored what it might look like to track progress at an individual level and allow goals to nest within a larger team-based hierarchy. This sketch also raised early questions like whether to include a sidebar for easy navigation and how to visually support the idea of subgoals and progress bars for each team member.
One of our most significant design decisions early on was the introduction of a branch system to represent cross-functional teams across Solidigm’s global structure (ex. OPX, GCC, AMR). This structure enabled the grouping of OKRs and task progress within sub-teams, aligning with how the company operates in reality. We also considered how this branching would allow managers to switch between regions and teams while maintaining visibility over shared objectives.
This mid-fidelity wireframe shows a dashboard view where each OKR is displayed in a collapsible format, allowing users to see high-level goals as well as nested subgoals with corresponding team members and their progress. This design prioritized readability and provided a clear assignment of responsibility, which became a guiding principle in the rest of our UI.
As we further refined the interface, we considered the experience from multiple user perspectives, such as team leads, individual contributors, and executives. Each role needed to access task data differently. Team members needed a simple, digestible view of what they were responsible for, while higher-level users needed broad overviews across multiple teams and branches.
This flowchart presents the full user journey, showing how a user transitions through various states in the application, whether they are a manager, team member, or unassigned user. It also reflects how the same core views dynamically adapt depending on who is logged in and what semester is selected, reinforcing the modularity of our design system.
Through these iterative sketches and wireframes, we were able to test concepts, refine the information hierarchy, and establish a shared design language for our team moving forward. This early phase of design allowed us to explore a wide range of possibilities while staying agile in our decision-making. The low-fidelity phase proved essential in identifying what mattered most to different users and laid the groundwork for a scalable, role-based UI architecture. Key outcomes of this phase included:
- Clarifying navigation flows and user roles across the platform
- Validating the concept of a branch-based hierarchy for organizing teams and tasks
- Prioritizing features like reporting, filtering, and real-time feedback based on user input
- Ensuring that the layout and content structure supported both individual contributors and higher-level managers
These insights directly informed our transition into mid- and high-fidelity designs, ensuring that our final product was grounded in real user needs and scalable for long-term use.
User Testing
For user testing, we did five rounds from 5 different employees in the CTE team at Solidigm. Participant roles ranged from team members, managers, to team leads. For each session, the time tested ranged from 30 minutes to 2 hours.
We gave them briefs on what the tool was, and gave them example tasks to complete on their own, while we took note of their behavior. We had them voice out their thought process out loud, so we could note any complications, frustrations, or appraisals for the tool. We also asked for their feedback on what the tool could used in order to be improved and more streamlined.
1. Interview #1
During our first user testing session, we observed that the participant experienced significant confusion regarding the way employee hierarchy was represented within the tool. The structure we implemented did not align with their understanding of the company’s actual reporting lines, leading to disorientation and extra effort to complete basic navigation tasks. This mismatch caused friction in task execution and made the interface feel unintuitive.
Key Takeaways:
- Align the internal tool’s hierarchy with Solidigm’s real-world organizational structure
- Restructure the employee model to reduce confusion and cognitive load
- Improve navigation and prioritize visibility of critical features
2. Interview #2
The second user provided largely positive feedback. They found the interface functional and particularly praised the reporting feature for offering clear insight into team progress. They also expressed enthusiasm for the Workday integration, seeing it as a key advantage in aligning task tracking with existing company workflows.
However, the participant raised a valid concern about role-based task flows. They pointed out that different employee levels may require different functionalities or access paths depending on their responsibilities.
Key Takeaways:
- Ensure the system supports flexible workflows based on employee roles and levels
- Continue enhancing Workday integration as a valuable feature
- Maintain scalability without overwhelming users in different roles
3. Interview #3
In the third session, the participant focused on visual clarity and task customization. They felt the current color system, used to indicate task progress, was misleading and suggested that color coding should instead represent urgency or deadlines. Additionally, the user felt overwhelmed by the task overview interface and requested a more advanced filtering system.
They also recommended granting higher-ranking employees greater customization power, such as the ability to create and manage custom tasks and workflows.
Key Takeaways:
- Redesign the color system to reflect task urgency instead of progress
- Implement a more intuitive and powerful filtering system
- Allow greater customization for users in leadership or management roles
- Continue building on the intuitive aspects of the interface and maintain strong reporting capabilities
4. Interview #4
The fourth participant emphasized a lack of system feedback. They reported confusion around whether actions — like submitting a form or creating a task — had been successfully completed. Additionally, they encountered scrolling bugs, long dropdown menus, and a filtering system that felt overwhelming.
They proposed improvements such as clearer status indicators, real-time feedback, better UI icons, and a more streamlined navigation experience. Despite the criticisms, they praised the sidebar layout, the Workday integration, and the tool’s file linking features, which helped bridge workflows across platforms.
Key Takeaways:
- Improve system feedback and status visibility for user actions
- Resolve usability issues like long dropdowns and scrolling bugs
- Enhance visual hierarchy and navigation
- Retain and build upon integrations and cross-platform linking features
Across all four user interviews, several key themes consistently emerged, providing valuable direction for refining our platform. First, there was a strong emphasis on alignment with existing organizational structure: users found it confusing when the hierarchy in the tool did not match real-world team and reporting lines. This reinforced the importance of mirroring Solidigm’s internal framework to ensure intuitive navigation and reduce cognitive friction. Additionally, flexibility stood out as a major need: users across roles requested more adaptable workflows, customizable task definitions, and role-specific functionality that caters to the varying responsibilities of different employee levels.
Hi-Fis (Post User Testing)
After getting feedback from Solidigm employees and managers, we redesigned pages that needed clarity and implemented additional features that team members advocated for. Hearing what users had to say cleared the way for us to polish up designs and send the final handoff to developers.
OKR Overview page — Managers can access a quick snapshot of Solidigm branch progress.
Buckets — Under company branches, managers can assign new buckets (subgoals) that align with the overall branch objective.
Tasks — A closer look at specific tasks assigned to team members and their reported progress.
Teams Page — Managers can view team progress under branches.
Creating a New Task — A more in detail view of users in a team assigning themselves a task
Reports — Employee work reports are consolidated in this page for Managers to review.
Workday Integration — Employees can use this page to fill their Workday tasks without opening a new application.
Admin Dashboard — Higher level managers can manage system and user access and settings.
Development
Take #1 Tech Stack: React/Nextjs/Supabase
When we began this project, we initially chose to build it using Next.js with React 18 for several reasons. Next.js provides a robust framework for building full-stack React applications with features like server-side rendering, static site generation, and API routes built-in. The choice of React 18 brings modern features like concurrent rendering and automatic batching, which are particularly beneficial for the complex data visualizations and real-time updates required in this workflow management system.
The application leverages TanStack Query (formerly React Query) for efficient data fetching and client-side state management. This library was selected for its robust caching, seamless handling of complex data synchronization scenarios, and smooth integration with Supabase. Additionally, team members are already well-versed in its usage, enabling faster development and adherence to best practices.
On the backend, the application utilizes Supabase as a backend-as-a-service platform. Supabase offers integrated authentication, real-time database functionality, and automatic API generation. Its foundation on PostgreSQL and support for REST APIs aligns well with the team’s existing technical knowledge, ensuring rapid and reliable development. It pairs excellently with Next.js, as both support serverless architectures and enable seamless integration of API routes, authentication, and real-time features with minimal configuration.
For data visualization, the app employs Recharts, a React-based library built on top of D3.js, which provides robust and flexible charting capabilities. Recharts was chosen not only for its power but also for its simplicity and ease of use within React projects. Its declarative syntax makes it straightforward to integrate charts directly into JSX, allowing developers to build complex visualizations with less boilerplate code. The library supports a wide variety of chart types, such as bar charts, line charts, pie charts, and more, making it versatile enough to meet the app’s diverse visualization needs. Additionally, Recharts handles responsive design well, ensuring that charts look good across different screen sizes and devices. With built-in support for tooltips, legends, animations, and customization, it enables the development of an engaging user interface that communicates data insights clearly and effectively.
As the project progressed, our scope expanded significantly from its original intent. Initially, we were introduced to just one or two use cases centered exclusively around the CTE team at Solidigm. The application was designed with these specific workflows in mind, and our tech stack, centered on Next.js, React, and Supabase, was well-suited for rapid development and rich interactivity. However, as we continued development, Solidigm requested that the tool be extended to support OKRs and task tracking across the entire organization, not just the CTE team. Given the broader requirements and the need for a more scalable foundation, our team collectively decided that the best course of action was to rebuild the application from the ground up to accommodate these expanded use cases and organizational needs.
Further discussions with Solidigm’s internal IT team revealed important constraints that influenced our technical direction. They shared that their infrastructure is primarily built around Azure and .NET, and they expressed hesitation around adopting solutions built with React or relying heavily on third-party JavaScript libraries, citing security and maintainability concerns. Given that company-wide adoption was a key objective, we determined that continuing with a React-based solution would not align with Solidigm’s internal practices and long-term strategy. To ensure seamless integration, maintain trust with the IT department, and improve the chances of enterprise-wide deployment, we made the strategic decision to rebuild the application using .NET technologies, aligning it closely with Solidigm’s existing internal stack.
Take #2 Tech Stack: .NET transition + Azure
Backend
After a lot of brainstorming about how the backend should look in .NET, we came up with a hierarchical structure that helps organizations track their goals and progress. At the top level, we have Branches(ex- CORP, GSG, CTE) which represent major objectives. These branches contain Buckets, which are collections of related tasks. Within these buckets, there can be optional Groups that further organize the tasks. These tasks definitions can have instances, with the progress of each task being an average of the progress of the instances. The core of the system revolves around task tracking. Each task can be tracked in two different ways: either as a percentage (like “75% complete”) or as a numeric value (like “7 out of 10 items done”). This flexibility allows teams to track different types of work most appropriately. Tasks are assigned to specific team members, and their progress is updated over time.
The system automatically calculates progress at every level. These calculations flow upward through the hierarchy: individual task progress combines to show team progress, team progress combines to show branch progress, and so on.
A key feature of the system is its ability to track progress over time. It maintains both current progress and historical data. Each month, the system takes a snapshot of all progress, allowing users to look back and see how things have changed. This historical tracking is particularly useful for understanding trends and making future projections.
The system is organized by semesters, with all teams and tasks being associated with specific time periods. This semester-based organization helps keep the data relevant and manageable. Users can only see data for their assigned team unless they have administrative privileges, which helps maintain data security and relevance.
Progress calculations are handled automatically by the system. When viewing current data, it uses the latest progress values. When viewing historical data, it pulls from the monthly snapshots. The system also tracks progress changes between months, showing how much progress has increased or decreased over time. All of these calculations are handled in the backend using services.
Database
To support the application’s data requirements at scale and to align with Solidigm’s internal infrastructure, we transitioned to using Azure SQL as our cloud-hosted database solution. Both the SQL Server and the .NET-based web application are deployed on Azure, allowing for centralized management, high availability, and smooth integration between services. This architecture not only meets enterprise-grade performance and security expectations but also simplifies the deployment pipeline for user testing and future production rollout. This stack was mainly for user testing, however, as once we handoff to Solidigm’s team, we will dockerize this set up and let them host it internally on-prem. Here’s how a typical Azure architecture flow looks like:
On the code side, the codebase utilizes Entity Framework Core (EF Core), a modern ORM that enables object-relational mapping between our .NET entities and the underlying SQL tables. We selected the Microsoft.EntityFrameworkCore.SqlServer provider to ensure tight compatibility with Azure SQL. Within our application, the ApplicationDbContext class serves as the bridge between the object model and the database, defining and enforcing schema rules such as relationships, constraints, and indexing. Our schema is intentionally designed with a high degree of normalization and relational integrity, reflecting the complexity of real-world OKR and task workflows across various branches, semesters, and teams.
Each data model is mapped with careful consideration of relational dependencies. We defined primary keys, composite keys, and unique constraints to preserve data accuracy and prevent duplication. Additionally, foreign key relationships are configured with precision, especially in cases involving hierarchical structures like parent-child branches or nested task instances. We also applied explicit deletion behaviors to avoid cascading deletes that could unintentionally remove important historical or related records, ensuring data stability even as the application scales.
To maintain clean separation of concerns, we developed a modular service layer that handles all database interactions. Rather than embedding database logic directly into UI components, we encapsulated operations into dedicated service classes. These services leverage dependency-injected context factories, which allows each service to instantiate its own database context per operation. This architecture improves maintainability, enhances testability, and prevents state-related issues in the context of Blazor Server’s real-time component model.
In addition to traditional CRUD operations, our services support advanced queries with eager loading of related entities, which enhances performance and user experience. State is also tracked across components using reactive services like the SemesterStateService, which keeps the application contextually aware of the currently selected semester and month. Together, this ecosystem of tools and architectural choices forms a scalable, enterprise-ready backend capable of supporting evolving needs across teams and business units at Solidigm.
Schema
Our database is organized hierarchically to align with Solidigm’s current workflow. Each work sprint is designed to be the duration of a semester with two semesters making up the calendar year. Each semester is then linked to its own set of branches, teams, buckets, tasks as projects, goals, and personnel change throughout the semester.
Rather than linking a semester to a set of branches, teams, buckets, and tasks, we linked semesters to branches, which would then connect to teams and buckets in a hierarchical order. This ergonomic decision allowed a simpler and more efficient database structure for better troubleshooting and more efficient operation time.
Each branch would share the responsibility of managing it’s own progress and parent through the hierarchy, whereas each bucket (created by the organization-wide branches) would pick its own set of tasks and personnel to maintain. Each team would consist of information about their parent branches as well as well as semesterly personnel-related changes.
The users have their own section to store their login information, which then linked to a specific semester, a role, a team, and a task that the user might be a part of. Allowing for a specific user to semester table keeps user information independent of any team relocations, which would be updated in the UserSemesterTable. The main goal behind the design of this schema was to limit the number of redundant connections while maintaining optimal interconnectivity and flexibility within the data.
Frontend
After making the switch to .NET, we decided to use Blazor as our web development framework. Like React, Blazor uses a component-based architecture, allowing us to build reusable, self-contained Razor components. This helped to reduce the learning curve for our developers as they adapted to the new tech stack.
After switching to Blazor, we also decided to change our styling library from Tailwind to Bootstrap because it integrates well with Blazor and the Razor components we were building, while also requiring less setup to function with a .NET application. Although Bootstrap’s more semantic and component based structure differs a little from Tailwind’s utility-first architecture, the layout and frequent use of our CSS classes made the transition a little easier for the development team.
However, our change in technologies was not perfect. Although the structure of Blazor is similar to React, we did have to adapt our JavaScript frontend logic to work in C#, which definitely changed the way we handled states, reactivity, etc. We also ran into some issues when switching over from Tailwind to Bootstrap, especially in regards to customization — a lot of custom styling we had already build in the Next application didn’t carry over well with Bootstrap classes, so we had to build out a lot of those styles globally. Additionally, a lot of Bootstrap default styling was overriding our custom styling, so we had to work around that and restructure some of the component’s CSS.
Docker Handoff
We chose Docker as the core method of packaging and handing off this application to make deployment seamless and client-friendly. We containerized the core .NET web application and its SQL Sever database, creating a portable and consistent runtime environment that can be spun up with a single command. This ensures that our app will behave reliably across environments, whether it is being run locally for development, or in Solidigm’s internal infrastructure for production.
We initially considered a cloud-hosted deployment, which we did use for user testing, but this introduced several concerns. Handing off a cloud-based setup can be tricky in terms of managing credentials, cloud costs, and access controls, and Solidigm also preferred to host the application on-premises due to data security concerns and the desire to leverage their existing infrastructure. Given these, Docker was a natural fit, with no reliance on third-party cloud services.
To support this setup, we built Dockerfiles and a Docker Compose configuration to coordinate both the app and database containers. The containers can be launched with a simple command, and once hosted on-premises, can be easily accessed by employees without introducing any external dependencies.
Reflection
Challenges
One of the most significant challenges we encountered during the project was the transition between tech stacks. We initially began development using a React/Next.js framework, which aligned well with our team’s experience and enabled rapid prototyping. However, after discussions with Solidigm’s IT department, it became clear that React and other third-party JavaScript libraries were not ideal for long-term adoption due to security and maintainability concerns. As a result, we made the strategic decision to rebuild the entire application using .NET and Blazor, aligning with Solidigm’s internal tech ecosystem and Azure infrastructure.
This shift introduced a steep learning curve, as none of our team members had prior experience with .NET development. Adapting to an entirely new ecosystem required a great deal of time and effort. Some of the specific challenges we faced included:
- Learning and applying C# syntax and .NET project structure from scratch
- Understanding Blazor’s component-based architecture and its differences from React
- Implementing Entity Framework Core for data modeling and database interaction
- Setting up Azure SQL databases and deployment pipelines within the Azure portal
- Debugging unexpected behavior due to unfamiliar tooling and runtime environments
Despite these obstacles, the process pushed us to grow technically and collaborate more effectively as a team. By the end of the transition, we had successfully built a scalable, maintainable, and enterprise-ready platform that conformed to Solidigm’s internal requirements.
Takeaways
Working on this project gave us the opportunity to step far outside the classroom and into a professional development environment. One of the biggest technical learning curves for our team was working with .NET. Most of us primarily worked with React, so working in .NET was a shift. Unlike React, where much of the logic happens on the client side with a wide array of tools, .NET centralizes functionality on the server, with fewer tools but tighter integration. It was a refreshing change of pace, but definitely took some time to adjust to the different development mindset.
Another major takeaway was just how seriously we were treated by our client, Solidigm. It was clear from the start that this wasn’t just a university collaboration for them; they genuinely intended to use the application we were building. That was both an honor and a challenge. We had strict and high-stakes deadlines, and while the team at Solidigm was always supportive and understanding, they also had real expectations. This meant we had to learn how to adapt quickly, as both our requirements and timelines could change with little notice. Rather than seeing this as a hurdle, we took it as a vote of confidence in our ability to deliver and it made us push ourselves in ways we hadn’t experienced before. It was a rare and valuable experience to be held to professional standards while still being students.
We also learned a lot about how companies operate, especially in terms of strategic planning and goal tracking. The app we were building was meant to track OKRs and we had never really seen how this kind of structure played out in a real-world context. It felt like getting a glimpse into the high-level operations of a company, beyond just team-level task management. It gave us perspective on how businesses align their goals across departments, how progress is evaluated, and how broader values are turned into measurable outcomes.
Finally, and maybe most importantly, we learned what we could accomplish as a team. There’s no real blueprint for an OKR tracking app other than a plethora of CSVs, so we were all constantly figuring out both the product and the problem space as we went. We had to pivot and redesign our application multiple times throughout the project. One of the most intense moments came when, due to a sudden shift in the project scope and timeline, we had to rebuild the entire app in .NET, along with new features, within a week. It sounded impossible, but we did it. That experience showed us how capable we were when we worked together and stayed open to being pushed. It was quite rewarding to see how far we could go, even under pressure.
Closing Remarks
This CodeLab x Solidigm collaboration was historic for many reasons: this was one of the biggest companies CodeLab has ever collaborated with, we were in direct communication with several higher-ups from the company (including a Vice President!), they visited us in-person at UC Davis several times, and our team got the chance to visit them at the Rancho Cordova office as well, and get some free merch & lunch! (And that’s just the stuff we can think of off the top of our heads.)
These are things that no other client team at CodeLab has ever experienced before, so it was a truly one-of-a-kind opportunity that elevated the experience beyond a typical student-industry project. And it also paves the way for future partnerships between CodeLab and other large enterprise clients, proving that student-led teams can deliver high-quality, enterprise-grade solutions under real-world conditions. We worked really hard to understand Solidigm’s needs, adapt to unexpected changes like switching tech stacks, and deliver a tool that could scale with their internal operations: all while growing tremendously as engineers, designers, and collaborators.
This project challenged us, pushed us, and ultimately made us better: better designers, better engineers, and better thinkers & problem solvers. We would like to extend a special thanks to Olga Otte, Charles Anyimi, and Jasmin Vora for making this project possible, and for being extremely kind and communicative throughout this entire process. We truly couldn’t have asked for better points of contact. Their trust and feedback made this experience as impactful and rewarding as it was. If you guys are reading this, THANK YOU on behalf of all of CodeLab 💜💜
And finally, thank you, the reader, for reading all of this. We hope you learned something!
