Starting my first software development job was both exciting and nerve-wracking. As a fresh graduate with some foundational knowledge in programming, I thought I was prepared, but stepping into the professional world of development was a whole different experience. In the three months since I joined Nutrient, I’ve learned so much about web development, working on a team, and personal growth. I’m incredibly proud of how far I’ve come, especially with one project in particular: the Astro project. This blog post provides a glimpse into my journey, the challenges I’ve overcome, and some key takeaways that I wish I could tell my past self.

First impressions

When I first started working at Nutrient, I figured it’d be stressful, full of tight deadlines, chaotic meetings, and people yelling to get code shipped. But honestly, it’s been the opposite. Everyone’s super nice, the team vibes are strong, and the pace, while steady, gives you space to actually think and build. That’s not something I expected going into my first real development job.

Getting dropped into Astro

The main project I was brought in on is what we’re calling the Astro migration, which began with just myself and one other person, but is slowly expanding. It’s basically a total rebuild of our website using Astro. More specifically, we have two “websites”: a GitHub repository that hosts our blog posts and guides, and a Webflow site that holds our landing pages. The job with Astro(opens in a new tab) is to move everything to a single new repository. The catch: We’re building everything from scratch, and that’s both exciting and overwhelming.

I’d never touched Astro before, and a lot of the early days at Nutrient were just me trying to figure out how Astro even works. I had some initial thoughts to look into React-based tools or static site generators like Middleman, but honestly, none of that really helped as much as I’d hoped. Normally when I try to learn new things, I watch a lot of YouTube videos, but there aren’t many Astro videos to watch. For one, it’s only a few years old and it’s not as popular as Next.js or React, because Astro is mostly used for static site generation. It’s also not connected to a backend as much, which means there aren’t tutorials online explaining how to use it because it’s meant to be straightforward.

That was definitely one of the biggest challenges for me: I couldn’t just watch a YouTube video on how to do something and understand how it works. Instead, I had to jump into coding and see firsthand how things render, how data moves around on Astro, etc. But that’s also how I got up to speed on it so quickly.

Learning Astro

Astro is a modern static site generator — meaning it builds webpages that don’t transfer data to a backend system — that allows you to build fast websites. Since it just shows content, it’s ideal for things like documentation. Additionally, it’s unique because it focuses on delivering optimized static HTML and minimal JavaScript by default. One of the major benefits of this is that it’s super fast: It prerenders all our pages into static HTML when it first builds the project, and we don’t need to include much JavaScript unless it’s absolutely necessary.

For me, figuring out how to structure the pages and components in Astro was a major challenge at first. I was used to thinking in terms of JavaScript-heavy frameworks like React, but Astro works a bit differently. It uses components that are rendered at build time, rather than relying on client-side rendering by default. It also integrates easily with other frameworks like React and Vue, which made the learning curve a bit smoother.

We had to build everything from scratch. There was no starting with prebuilt templates or components. This made the initial process a bit overwhelming, but eventually, it allowed for more flexibility in shaping the website’s final look and feel.

The challenge with Starlight

When we started out, we were working with Starlight(opens in a new tab), which is a documentation theme built specifically for Astro. It’s designed to give you a simple, clean static site that’s already optimized for speed and supports Markdown. The idea is that it’s easy to set up and gives you a good base with default colors, a table of contents, a sidebar, text, and more. This gets you up and running quickly, but the fact that Starlight defined these components and styles for us meant we didn’t have any control over what it looks like.

We quickly realized that the flexibility we needed wasn’t quite there for our project — especially in terms of customization, so we ended up having to build out something in-house that suits our needs better, in addition to matching the look and feel of our brand and design vision. This gave us more freedom to adjust everything according to the project’s needs, but naturally, it was a lot of extra work.

The challenges of building a project from scratch

On that note, one of the biggest hurdles we faced was, unsurprisingly, building the sidebar. When we first started, the project was small — just 18 pages as a proof of concept of sorts — and it was easy to know what needed to go in the sidebar. But as the project grew and we began migrating more content, things got complicated fast. Suddenly, we had nested folders and various platform-based sidebar structures to consider, and the sidebar wasn’t as straightforward as we’d hoped.

Originally, our plan was to automate the sidebar based on the content in Middleman. The idea was to pull the data directly from the content itself. However, Middleman uses a separate JSON file, along with some YML files and a variety of frontmatter fields, to define the sidebar. It was a bit of a mess, and we quickly realized we didn’t want to carry over that complexity to Astro. This is because a large part of why we were moving to Astro was because the existing site was more than a decade of this kind of mess, and we wanted something clean and uncomplicated.

We tried at least three different iterations of the sidebar, but each one ended up more complicated than we wanted. After spending way more time on it than expected, we came to the conclusion that the best approach was to stick with something similar to what we had in Middleman. In the end, we opted to use the same JSON and YML file structure, which now works fine. But it was definitely a learning experience — my main takeaway was that trying to implement an efficient solution requires careful planning and a lot of consideration for alternative approaches. And just because we want to simplify how something is implemented, that doesn’t mean we can just rush into it without careful planning on how to implement it.

Working through the challenges

Even though I haven’t been at Nutrient that long, I remember those first few weeks I felt like I was in the deep end — everything was new, and I was trying to figure out how all the pieces fit together. There were times when I’d clock in at 8 a.m. and work until late evening just trying to understand how components fit into the larger architecture of the site.

I spent a lot of time experimenting with how to structure Astro’s components and how to use Astro’s file-based routing. Once things started to click, I realized how much simpler some tasks could be in Astro, like creating static pages and routing them, without worrying about complex configuration. This made me really appreciate the value of using Astro over alternative frameworks like Next.js or Vue.

A major challenge came when dealing with styling and layout consistency across the site. Since we were building everything from scratch, it was essential that we set up our project with the proper architecture. More specifically, it was important for us to clearly define what folders would hold our page templates, our Markdoc content pages, our route-based Astro pages, our Astro component pages, etc.

Teamwork and guidance

I’m not doing this alone, of course. The team — specifically my manager, Cosmin — plays a huge role in guiding the project’s direction. Cosmin makes sure my work aligns with the larger project goals, and that’s important because it helps me make sense of my contributions and how they fit into the bigger picture. He’s also a really good manager and a supportive teammate, and if I do something wrong, he’s kind about it. What’s more is I know I can actually learn from him, because he’ll specifically point out what I need to do and what needs to be changed. That feedback is an essential part of my success here so far.

At times, I feel a bit out of my depth, but having a supportive team means I can always ask for help. One of the key takeaways from this experience has been learning how to collaborate, ask questions, and take the time to make sure things are done right.

Of course, sometimes no one is available when I have a question — this is a downside of a remote job. When this happens, I just instead experiment with a bunch of other approaches I can use. For example, if I can’t figure out how to use a partial, I try my own component, or another library. This in turn strengthens my competency and confidence as a developer, because when I encounter a problem with multiple potential solutions, I have to decide the best one.

What I’m working on now

Currently, I’m working with Shan from the Hybrids team to finish up the guide pages. These pages are essential to the website, and since there are a ton of them, they’re a major piece of the puzzle. Meanwhile, Cosmin and Alexandros from the Web team just finished migrating the blog and will start working with us on the guides. Once those are done, we’ll focus our efforts on digging into Webflow, which will be a whole new challenge of its own. Honestly, I’m terrified just thinking about it, but I know once we get started, it won’t be such an intimidating process and we’ll figure it out.

But after that’s done and the new website is up and running, the work will mostly focus on maintenance — ensuring the site stays updated, fixing any bugs, and making improvements when I see opportunities. It’s a bit different from the build phase, but it’s equally important to ensure that what’s already built stays fresh and functional.

Lessons learned

If I could go back and talk to myself on day one, I’d tell myself not to stress so much. You don’t need to have everything figured out immediately. Take your time to learn what you need for a project and don’t be afraid to ask questions. You’re going to learn a lot more by doing, even if it’s messy at first.

The Astro migration has definitely been a challenge, but it’s been a good one. It’s forced me to get out of my comfort zone and learn how to build a website from the ground up using a new toolset. It’s been an eye-opening experience, and looking back, I’m proud of how far I’ve come. Not just because of the site we built, but because of how much I’ve learned about development, problem-solving, and teamwork. It’s also so cool to see that I am capable of taking all the technical skills I’ve learned in my studies and applying them in a real workplace setting. I really like that I’m able to create a product — in this case, a website — that people can use.