Forem: kate astrid

From Chaos to Clarity: Fixing Our Monorepo

kate astrid — Tue, 19 Aug 2025 11:45:37 +0000

Introduction: Why This Story Might Save You Some Headaches

If you’ve worked in a large codebase, you’ve probably seen this: the code runs, but every change takes far longer than it should. Updating one feature often breaks another. Adding a dependency means worrying about conflicts. Old build tools still linger, and no one feels safe upgrading packages that half the system depends on.

That’s exactly what we faced in our journey-monorepo, the main repository for our team. Dependencies were wired together in inconsistent ways, different teams had introduced multiple overlapping build tools, and some libraries hadn’t been touched in years. Proposing a cleanup felt like asking to redesign a city while people were still living in it — risky, disruptive, and easy to delay indefinitely.

So why did we bother?

Development had slowed to a crawl. Builds were taking too long, and waiting minutes just to see a change in the browser was killing productivity.
Every change felt risky. The dependency spaghetti meant a small tweak in one package could break multiple apps — often in ways we wouldn’t notice until much later.
Onboarding new developers was painful. It took too long for new team members to get up to speed, mostly because they had to learn multiple bundlers, testing setups, and outdated tooling quirks.
Technical debt was blocking new features. We were spending more time patching, debugging, and wrestling with the repo than building the actual features our users cared about.
Costs were adding up. Longer build times meant higher CI costs, and outdated packages made security updates and maintenance more expensive in the long run.

In short, the longer we waited, the more time, money, and momentum we were losing.

And, hey, now we get a good story out of it.

Journey-Monorepo in a Nutshell

Journey-monorepo is the central place on the epilot platform for everything related to journeys. What you see in the screenshot above represents two main apps: journey-app on the left side and journey-builder on the right. Journey-builder is responsible for configuring journeys, and journey-app for rendering them.
Like in many startups, the repo started out clean and well-structured, but as the product grew quickly, the codebase expanded in unplanned ways — things were added wherever they seemed to fit at the time.

The “BEFORE” Setup

Apps:
- journey-builder.               
- journey-app
- entity-mapping
- journey-view

Packages:
- blocks-configurators
- blocks-renderers
- journey-elements
- journey-utils
- journey-logics-common

Let me show you the rough map of dependencies we had step by step. We are interested in two main apps: journey-builder and journey-app, so I am going to dive deeper into their connections. It is not important which app or package does what. What IS important is to see how many connections we had to keep in mind every time we needed to change anything.

Ok, this is fine.
This is too.
Yeah, cool.
Packages already become tangled, let's keep going.
Ok, even more connections.
Well, this is just a delinquent madness.

You might say: Kate, come on, this is what happens in every big project - things become deeply intertwined, and it is a normal thing to experience.
I will answer: yes, but I haven't finished.

Let's now add the build tools to this table to have the full picture.

Well, what we have here:

Webpack;
Craco;
Tsup;
Tsx;
Tsdx.

I don't know about you, but I hadn't worked with half of them before I started working on this repo.

In the end, it was a web of “if you change this, you might break that” — and “that” could be anywhere.

How We Tackled It

We kicked things off with an RFC — basically, “let’s write this down so we don’t lose the plot halfway through.”
Our two big goals:

Unify the tooling so we weren’t juggling five different build setups.
Untangle dependencies so teams could work without stepping on each other’s toes.

And this is exactly what we did.

Step 1: Cut the Cord on Unnecessary Dependencies
The first thing we had to do was face the dependency jungle. Over time, different teams had introduced overlapping packages, and no one was quite sure what depended on what anymore. Cleaning this up gave us a chance to regain control.

Untangled all the apps and packages as much as possible. We mapped out how everything connected and then started cutting back the unnecessary links. This meant reducing cross-dependencies that caused fragile builds.
Moved blocks-configurators into journey-builder. These configurators were never meant to be used outside, so pulling them closer to where they belong simplified the dependency graph.
Moved blocks-renderers into journey-app. Renderers were core to the application itself, so consolidating them in the main app made the architecture more intuitive.
Deleted journey-utils and journey-elements. Journey-utils was a very small package with some utilities that were moved to other packages. And journey-elements _ were later replaced by _concorde-elements. You can read more about it in this article written by my partner in crime.

This was a painful step, but once the dust settled, the repo felt lighter and easier to reason about. We no longer had to worry about accidentally breaking other parts of the system when making small changes.

Step 2: Standardize the Tooling
After trimming the dependencies, the next big challenge was our tooling. Different parts of the repo used different build systems, which slowed everyone down and made onboarding new developers a headache.

Phased out Craco, Tsup, and Tsdx by switching to Vite. These older tools had been added over time, each solving a narrow need. Vite gave us a unified, modern setup with faster builds and simpler configuration.
Swapped Jest for Vitest — faster tests, modern setup. Jest had served us well, but it was slow and required custom patching to keep working. Vitest gave us near-instant feedback and worked seamlessly with Vite, making the dev experience far smoother.

By unifying the tooling, we not only sped up day-to-day work but also reduced cognitive load. Developers no longer had to remember which tool applied to which package — everything just worked the same way everywhere.

This is how the "AFTER" setup looks:

As you can see, the monorepo is now far more streamlined — there are significantly fewer dependencies crisscrossing between packages, and we’ve eliminated most of the variations in build tools. This makes the structure easier to understand, faster to work with, and much less fragile when changes are introduced.

After the Restructuring: What We Learned

When the dust settled, it wasn’t just that the dependency graph was cleaner — we were thinking about the repo differently.

Immediate Wins

Changing things stopped feeling dangerous. Before, touching a shared package felt like pulling a brick from a Jenga tower. Now, fewer connections mean less risk.
Builds and tests stopped feeling like a punishment. Vite’s dev server = instant feedback. Vitest shaved minutes off test runs. Devs started running tests more often just because they could.
Onboarding went from “ugh” to “okay.” New folks could get set up without learning the quirks of four bundlers first.

Slower Payoffs

- Tooling swaps aren’t magic. Some Webpack plugins didn’t have a Vite equivalent, so we had to rethink features or drop them.

- Vitest exposed bad tests. Some “passing” tests were only passing thanks to Jest’s quirks. Painful, but worth fixing.

Trade-Offs & Reality Checks

- Not everything got unified. A couple of apps still run on legacy setups because migrating them wasn’t worth the risk — for now.

- Shared packages need rules. We now ask “does this really need to be shared?” before creating new ones.

- Refactoring is never “done.” There is always room for improvement, we all know. that.

Tips If You’re Thinking About Doing This

Draw your dependency graph before you start — it’ll help convince others (and yourself) that the cleanup’s worth it.
Expect setbacks. Some PRs will break things. That’s normal.
Automate checks for unused or outdated packages — saves a ton of review time.
Celebrate small wins. Removing the last Webpack config deserved cake.

Final Thoughts

This wasn’t a quick tidy-up — it was a half-year-long deliberate overhaul alongside working on other features. But it’s made a massive difference to how we work: faster builds, fewer “don’t touch that” areas, and a general feeling that the repo is ours again, not a beast we’re afraid of.

If I had to wrap it all up in one bit of advice?

Keep it simple.

Every extra dependency, tool, or package you skip today is one less thing you’ll have to untangle in the future.

What To Expect When You Join Epilot

kate astrid — Mon, 03 Feb 2025 13:24:46 +0000

Hey you, awesome engineer.

Let's imagine that you are joining epilot tomorrow. Would you like to have a sneak peek at your nearest future?

Here’s a quick rundown of how we onboard new team members—no stiff formalities, just a clear path to help you settle in, understand our product, and get involved fast.

A Friendly Start
On the day one we’ll introduce you to your team lead and a dedicated onboarding buddy—think of them as your go-to guides for all things at epilot. Need pointers on our processes, product roadmap, or just want to figure out who to chat with about a certain topic? They’ve got you covered.

Your First Week

Get Set Up
We’ll make sure you have all the hardware, software, and accounts you need from day one. We’ll give you a handy checklist so you can get everything in place without the guesswork. Of course, your onboa buddy is always there to help you with everything.
Meet the Team
You’ll be given a chance to schedule 1:1 with every team member to get to know them better. Regardless of being remote-friendly company, we value real connections and friendly relationships, and make sure that everyone feels valued and supported.
Learn About Our Product and Users
We’re a high-touch SaaS company, and our product is complex and full of internal terms and abstractions. It might feel overwhelming in the beginning, but don't worry, we've got you. You will be given lots of resources like recordings of product demos and docs about different topics about epilot. No rush—just learn at your own pace and ask all the questions you have.
Get a Feel for Your Team’s Culture
Every team at epilot has its own rhythm and habits. Hop into Slack conversations, daily stand-ups, and team meetings to get a sense of what’s going on and how decisions get made. And feel free to share your ideas and suggestions - we are always eager to improve.
Start Contributing
We think the best way to learn is by doing. Early on, you’ll probably tackle a small assignment to get familiar with our systems and processes. Consider it your first real taste of epilot in action.

Getting to Know the Wider Company
Throughout your onboarding, you’ll also have chats with:

Founders: Hear the backstory behind epilot and our long-term vision.
Department Heads: Whether it’s Sales, Marketing, Engineering, or Product, each leader will fill you in on how their team supports our bigger goals. The idea is to see how all the pieces fit together and create the vibe.
Engineering & Product Leads: If you love diving into tech details, these sessions will give you insights into our architecture, tools, and future product plans.

Seeing the Product in Action
Our platform is built around microservices, but don’t worry if that’s new to you. We’ll walk you through the basics. We also encourage you to check out how our customers actually use epilot—like checking live customer feedbacks. It’s a great way to see what’s working and where we can improve.

The Balance Between Work and Collaboration
At epilot, we keep things productive but also supportive:

Team Events: You’ll get invites to company-wide announcements, product demos, company events, and more.
Open Communication: Slack, shared docs, and frequent check-ins mean you’ll never be left guessing.
Culture Matters: We appreciate everyone’s contribution, whether it’s project-related or just sharing something fun. We are the team, and this is what matters.

Looking Ahead
After a few weeks, you’ll have a good handle on how things work here—and you’ll know who to reach out to when you need help. We’ll likely ask for your thoughts on onboarding so we can keep improving the process for the future.

If this relaxed but purposeful approach resonates with you, we look forward to hearing from you. At epilot, we want every new hire to find their footing, make meaningful contributions, and grow in their role—without all the usual corporate fluff.

Happy to have you on board ✨.

Have you heard about the anterior midcingulate cortex?

kate astrid — Sun, 07 Jan 2024 20:45:07 +0000

The anterior midcingulate cortex (aMCC) is an amazing area in the human brain that plays a vital role in decision-making, emotional processing, and even pain perception. More interestingly, it acts as a crucial network hub for those tough cost/benefit calculations that fuel our perseverance, willpower, and tenacity.

Let's talk about facing challenges. Whether it's cracking complex equations or gearing up for a marathon, we all respond differently. Some might find the effort too overwhelming and step back, while others dig in their heels and push through without immediate rewards. This trait of persistence, increasingly spotlighted in research of the aCMM, correlates with better outcomes in health, academics, and career success.

Now, here's where it gets really cool: when programming, especially during those head-scratching moments that we might not particularly enjoy, our aMCC gets super active. Ever found yourself in a coding conundrum, feeling frustrated to the point of wanting to quit? That's your aMCC in action, getting stronger. It's akin to facing a steep climb while running; challenging, maybe not enjoyable, but incredibly effective in building mental strength and resilience.

So, remember, pushing through a tough coding problem does more than solve an issue on your screen. It's an aMCC workout, enhancing your brain's capacity to navigate complex tasks and manage emotions. It's a double win - improving your coding skills and boosting brain power, even when it feels tough at the moment =).

Nice to know, right?

Common Cognitive Biases That May Affect Us As Developers

kate astrid — Sat, 16 Sep 2023 10:38:14 +0000

As developers, we need to think straight to create solid, clean code. But hey, we're all human, and sometimes our brains make errors that can muddle up our decisions. Scientists call these errors cognitive biases. They can lead us down the wrong path, but they're actually part of how our brains handle the crazy amount of information we get all the time. Without these biases, it would be super tough to process everything logically.

Still, it's important to keep these biases in check, as they can twist our view of reality and lead to not-so-great decisions. So, I thought I'd share some common biases that we, as developers, can bump into:

Confirmation Bias: We might lean towards solutions or tech that fit with what we already know or believe. This can stop us from picking up something that could be even better.
Anchoring Bias: We sometimes stick too much to the first piece of info we get (the "anchor") when we're making decisions. For instance, we might guess how complex a task is based on something similar we've done before, even if it's not really the same thing.
Dunning-Kruger Effect: If we're not that experienced, we might think we're better at coding than we really are. This can make us too confident and cause mistakes.
Survivorship Bias: We might only focus on the projects or tech that did well and ignore the ones that flopped. This can make us too optimistic about how likely something is to succeed.
Not Invented Here (NIH) Syndrome: Sometimes we might dismiss solutions made by others and end up making new tools or frameworks when we could just use what's already there.
Recency Bias: We might pay too much attention to things that happened recently, like a bug we just ran into. This could skew our view of how reliable a project or tech really is.

So there you have it, folks – a quick rundown of some of the mental trip-ups we might face as developers. It's essential to remember that we're all susceptible to these biases, no matter how skilled or experienced we are. By being aware of them, we can work smarter, make better decisions, and create code that really shines. Keep coding, stay aware, and let's build great stuff together!

Ten Red Flags That Obstruct Systems Thinking

kate astrid — Sat, 16 Sep 2023 10:33:59 +0000

Hey cool people! 👋

Today I want to share with you a piece of useful knowledge about systems thinking that helps me analyze systems and their connection to each other and allows me to improve my understanding of any process I interact with, be it companies, code bases, or even human bodies.

In general, systems thinking is an approach to understanding and solving complex problems by looking at the bigger picture. Instead of focusing on individual parts or events, systems thinking considers how those parts are interconnected and how they impact each other. This approach helps to identify the root causes of problems and create long-lasting solutions, rather than just addressing the symptoms. In simple terms, systems thinking is like looking at a whole forest rather than just individual trees, recognizing how everything is connected and influences each other.

There are ten statements — red flags — that act as obstacles to systems thinking:

“Let’s fix it quick!” While systems thinking doesn't demand slow problem-solving, hastily jumping into solutions without understanding the problem is counterproductive.
“Just put a Band-Aid on it.” Temporary fixes can hide symptoms while the underlying issue continues to harm the organization.
“We need the budget finalized!” Focusing on budgets and deadlines promotes linear thinking, moving away from systems thinking principles.
“We must respond right away!” Rushing to address problems encourages linear thinking, while calmly analyzing the situation fosters systematic thinking.
“Who cares?” Apathy hinders creativity and problem-solving, preventing organizational growth and effective solutions.
“We need more information.” Collecting data is important, but linear thinking arises when expecting data alone to solve problems without proper analysis and action.
“You are overthinking things.” Disagreements may be seen as overthinking. Systems thinking requires stretching beyond comfort zones and embracing complex solutions.
“Forget the rest of the organization.” Linear thinkers prioritize personal needs with win-lose solutions. Systems thinking seeks win-win solutions that benefit everyone.
“We don’t want any conflict.” Avoiding conflict at all costs can prevent addressing real problems. Confronting conflicts is necessary for effective problem-solving.
“We will do it this way.” Imposing one's will stifles creativity, innovation, and collaboration, hindering effective problem-solving and growth within the organization.

I truly believe that systems thinking can introduce new perspectives, reveal hidden problems if they exist, and help existing processes to thrive and prosper 💃 .
Lets's discuss it. Have you tried this approach? 👀

How to Maintain the Performance of a React Application on a Daily Basis

kate astrid — Wed, 06 Sep 2023 07:42:59 +0000

I'm a fast-paced person: I eat quickly, walk briskly, and make decisions in a snap. What I can't stand, though, is a slow app — especially one I'm working on. So, I always find myself compelled to scrutinise its performance: examining how many times it re-renders, the size of the DOM, and the speed of user interactions, among other things. Armed with this data, I incrementally improve the app's performance by refining the codebase in a targeted way.

Now, I'd like to share some strategies that could help enhance your app's performance:

Be Mindful of the Hooks You Use in Each Component: From my perspective, this is crucial. useState and useEffect are the most commonly used hooks, but sometimes they can be eliminated with a bit of refactoring, without sacrificing functionality. Fewer hooks mean fewer re-renders, which in turn means a faster app. Other noteworthy hooks are useCallback and useMemo, which memoize values, storing them in memory. On a larger scale, this can have an impact on performance. The same goes for React.memo().

Simple example:

Imagine you have a component that tracks a user's first name, last name, and age. A naive approach could be to declare three separate useState hooks:

const UserProfile = () => {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  const [age, setAge] = useState(0);

  // Multiple function calls to update the user profile
  const updateUserProfile = () => {
    setFirstName('John');
    setLastName('Doe');
    setAge(30);
  };

  return (
    <div>
      <h1>{`${firstName} ${lastName}`}</h1>
      <p>Age: {age}</p>
      <button onClick={updateUserProfile}>Update Profile</button>
    </div>
  );
};

Every time each of those hooks is called, the component will re-render, even if it happens simultaneously. We could condense this into a single useState by using an object:

const UserProfile = () => {
  const [user, setUser] = useState({
    firstName: '',
    lastName: '',
    age: 0,
  });

  // Single function call to update the user profile
  const updateUserProfile = () => {
    setUser({
      firstName: 'John',
      lastName: 'Doe',
      age: 30,
    });
  };

  return (
    <div>
      <h1>{`${user.firstName} ${user.lastName}`}</h1>
      <p>Age: {user.age}</p>
      <button onClick={updateUserProfile}>Update Profile</button>
    </div>
  );
};

Now, we have only one hook, and only one re-render when the hook is called. Bingo.

Minimise the Number of DOM Nodes: I always ask myself, "Can this HTML tag be safely removed?" If the answer is yes, I remove it. Fewer nodes lead to better performance.

Simple example:

If you find the code using empty divs solely for styling purposes, consider using CSS Grid or Flexbox to achieve the same layout, thus reducing the number of DOM nodes.

// Before
<div className="wrapper">
  <div className="innerWrapper">
    <Component />
  </div>
</div>

// After
<div className="optimizedWrapper">
  <Component />
</div>

Favor Class-Based Styling Over Inline Styles: Inline styles are considered new objects on each render, which can make React think something has changed, triggering unnecessary re-renders and affecting performance. It's also worth noting that maintaining styles in separate files helps keep the styling consistent.

Simple example:

// Before
<div style={{ display: 'flex' }}>

// After
<div className='container'>

// In a separate css file: 
.container: {
  display: flex
}

Prefer Simple divs to Box from Material UI or Similar UI Libraries: Native HTML elements generally offer better performance because they don't carry the overhead of additional React components, including lifecycle methods and context consumption.

Simple example:

// Before
<Box p={2}>

// After
<div className="container">

// In a separate css file: 
.container: {
  padding: '2px'
}

Prefer Conditional Classes to Conditional Styles in makeStyles from Material UI or Similar UI Libraries: Using predefined classes that are toggled based on conditions can be more performant, as it doesn't generate new classes at runtime.

Simple example:

// Before
const useStyles = makeStyles({
  root: {
    backgroundColor: props => props.isActive ? 'blue' : 'white',
  },
});

// After
const className = isActive ? 'active' : 'inactive';

Opt for Functional Components: There are several compelling reasons for this. First, functional components are easier for build tools like Webpack to optimize through "tree shaking," which only includes the code that's actually being used in the final bundle. Second, functional components often result in a smaller component tree and fewer lifecycle methods, allowing React's diffing algorithm to make quicker updates to the DOM. Lastly, functional components use less memory than class components, which is especially beneficial in environments where memory is limited.

Simple example:

// Before
class MyComponent extends React.Component {
  state = { /* ... */ };
  componentDidMount() { /* ... */ }
  render() { /* ... */ }
}

// After
const MyComponent = () => {
  const [state, setState] = useState(/* ... */);
  useEffect(() => { /* ... */ }, []);
  return (/* ... */);
};

By giving these tips a go and making them a regular part of your coding routine, you're not just on the path to a speedier React app, but you're also gonna make things a whole lot smoother for your users.
Let's create better apps together =).