When Mimiquate was founded in 2016, the intention was to build a company where technology and people mattered equally. A place where lasting relationships could be created, modern technologies could be explored, and people could do meaningful work while continuing to grow professionally.Ten years later, the company has changed in many ways. The projects have become more ambitious, the team has grown, and Mimiquate’s involvement in the broader software community has expanded.

But the principles behind the way the company works have remained remarkably consistent.

Mimiquate was founded in 2016 with the idea of creating a software company with its own identity.

At the time, Uruguay’s technology ecosystem was expanding rapidly, and starting a company felt both challenging and exciting. The founders wanted to explore technologies they believed in, work on interesting products, and create a place where people could develop their careers without sacrificing a healthy and human way of working.

Elixir became an important part of that identity from the beginning.

At the time, we were researching Elixir, and it felt exciting to start from there. It was not widely adopted, but we could see enormous potential in the language and its ecosystem. — Marcelo Dominguez, Mimiquate.

The founders were also thinking carefully about the kind of relationship Mimiquate should have with its customers.

The goal was never simply to receive requirements, complete tasks, and move on. Mimiquate wanted to become genuinely involved in the products and companies it worked with: to understand how its customers thought, act as part of their teams, and make decisions based on what would be best for them in the long term.

From the beginning, we believed that our customers’ success had to be our success. That meant putting our energy into understanding their goals and acting in their best interest, rather than thinking only about the immediate work in front of us. — Juan Azambuja, Mimiquate.

Over the last decade, the projects have evolved, the team has grown, and the scale of the challenges has changed significantly.

What started as a small software development team became a company working on complex international products and collaborating closely with engineering teams and organizations across different industries. Throughout that growth, Mimiquate’s approach to customer relationships has remained central.

The company aims to work as an extension of each customer’s team. That means understanding the product beyond its technical implementation, contributing ideas, raising concerns, and taking ownership of the results. It also means being honest when the team believes something should be approached differently, even when that conversation is difficult.

Over time, this way of working has created relationships built on mutual trust. Some of Mimiquate’s most important customer relationships have lasted for years, and many new opportunities have come through recommendations from people who already understood how the company worked.

That has been incredibly meaningful to Mimiquate. It confirmed something the founders believed from the beginning: long-term relationships are not created only by delivering good software. They are created by consistently demonstrating genuine care for the same outcomes as the people and companies involved.

We have always wanted people at Mimiquate to think and act as part of the customer’s team. When you genuinely care about their success, the relationship changes. You stop being an external provider and start becoming a trusted partner. — Juan Azambuja.

A decade is enough time for almost everything around a company to change.

The kinds of products Mimiquate builds have evolved. Its technical knowledge has deepened. The team has become more experienced, and the company has learned how to support larger and more demanding projects. Mimiquate also understands its own culture better than it did in the beginning.

Some of the principles that were initially informal eventually became explicit values within the company: responsibility, transparency, flexibility, companionship, and joy.

Giving people ownership over their work has always been an important part of that culture.

One thing I always wanted to encourage at Mimiquate was giving people ownership, while also allowing them the freedom to contribute ideas from their own perspective. The best results usually happen when people understand the goal and feel trusted to help decide how to reach it. —Juan Azambuja.

Many things have changed, but the collaborative mindset, the search for continuous improvement, and the willingness to adapt to each challenge remain part of Mimiquate’s identity today.

Contributing to the software community was something Mimiquate’s founders wanted the company to do from its early years.

The ambition was to work on open source projects, write technical content, share what the team was learning, and participate in conferences. In practice, however, making that happen was difficult at first.

During the company’s early years, working with customers required almost all of its time and attention. The priority had to be building a sustainable company, supporting the team, and delivering the kind of work that would allow its customer relationships to grow.

As Mimiquate became more established, it gradually gained the capacity to contribute more consistently.

Its involvement began through the broader Elixir community. Since 2016, Mimiquate has supported conferences and events connected to the ecosystem, both because the company believed in the technology and because it wanted to help the community around it continue growing.

Over the years, Mimiquate has sponsored many conferences, from smaller community events to major international gatherings. That support started during the company’s early years and continues today.

More recently, the company’s participation has expanded beyond sponsorship. Members of the team have written articles, built and maintained open source projects, and presented their work at international conferences such as ElixirConf.

These activities are no longer something Mimiquate wants to pursue only occasionally. The company wants them to become part of its DNA. Working on open source, writing, researching, and giving presentations allows Mimiquate to contribute to the ecosystem, but it also helps the team become better at its work. These activities encourage people to study ideas more deeply, explain them clearly, receive feedback, and develop skills that can be difficult to acquire through customer projects alone.

Technology communities grow when people share what they know. Contributing is valuable for the community, but it is also an important way for people to challenge themselves and continue developing professionally. — Marcelo Dominguez.

Bringing Communities Together in Montevideo

Two years ago, Mimiquate began organizing the Montevideo Elixir Meetup. Its goal is to help more people in Uruguay discover Elixir, create a regular space for those already working with the language, and strengthen the connections between the local and international Elixir communities.

The meetup gives people an opportunity to share projects, explore ideas, and meet others interested in the ecosystem. It also gives members of Mimiquate’s team a place to develop their presentation skills and share what they have been learning.

At the same time, Mimiquate wants its office to be useful to the broader local software community.

The company has started offering the space to other technology groups, including JavaScript, Python, and Ruby meetups. Different communities have their own tools and perspectives, but they often face similar challenges and have a great deal to learn from one another.

By opening its doors, Mimiquate hopes to make it easier for these groups to organize activities, exchange knowledge, and create stronger connections within Montevideo’s technology ecosystem.

Mimiquate also supports initiatives such as Open Web Uruguay, where people from different technology communities come together around a shared interest in building and sustaining an open web.

Mimiquate has always been a collective project.

The company aims to create an environment where people can grow professionally, participate in decisions, and become an active part of what is being built together. One of Mimiquate’s long-term intentions has been to support team members in developing their own careers and interests.

That can happen through customer work, but also through talks, mentoring, research, open source projects, technical writing, events, and independent experimentation. Mimiquate believes the company becomes stronger when people are encouraged to explore their interests, share what they learn, and take on challenges outside their usual responsibilities.

Importantly, this participation must also come from the company’s leadership.

It would be difficult to encourage the team to write, present, contribute to open source, or organize events without the company’s leaders being willing to do those things themselves.

I think it is important that people feel they can explore their own interests and ideas. A company grows when the people inside it are given opportunities to grow. — Marcelo Dominguez.

Reaching 10 years means realizing that culture is something you build every day. It is reflected in small decisions, in how people collaborate, and in the trust that develops over time.— Juan Azambuja.

The company wants to keep building software with customers whose products and goals it believes in. It wants to deepen its existing relationships and continue earning the trust that has made so much of its growth possible.

Mimiquate also wants to strengthen its contribution to the Elixir ecosystem and the broader software community.

That means continuing to sponsor events, organize meetups, maintain open source projects, publish technical content and share the team’s work at conferences. More importantly, it means creating the conditions for people throughout the company to take part in those activities.

Growth remains important, but it is not the only measure of progress.

Mimiquate wants to continue building a company where customers feel that the team is genuinely invested in their success, where people can take ownership and develop their careers, and where sharing knowledge is treated as a meaningful part of the work.

Ten years in, those ideas continue to guide what comes next.

10 Years of Mimiquate: What We’ve Learned and What Comes Next

Earlier this September, the Mimiquate team traveled to Chicago for another edition of ElixirConf US.

As we've experienced over the years, one of the things that makes ElixirConf especially valuable is the chance to bring the community together in person. Elixir is still a relatively small ecosystem, which makes having a space to meet the people behind the language, exchange experiences, discover what others are building, and discuss where the ecosystem is heading particularly meaningful.

Something new this year were the roundtable discussions: moderated conversations around a specific topic. The topics were really interesting (Building High-Performing Engineering Teams, Being a Junior Dev in an Agentic World, and How Should We Be Programming in the Age of AI, to name a few), but they ran in parallel with the two tracks of talks. That meant fewer attendees per talk, which is a bit of a shame considering how much time goes into preparing one.

After a few days of talks, conversations, and new ideas, we came back with plenty to think about. Here are some of the talks that caught our attention and the main takeaways we brought home from ElixirConf US 2026.

 as has become tradition over the last three years, José talked about the type implementation in Elixir. This time, though, he implemented the type system from scratch, live, which was pretty cool. It was great to understand the work from such a practical angle. The whole type system can be implemented with just three main operations, which is kind of crazy. José did a great job explaining how to type more complex structures and how the complexity of the type system grows, even though, in the end, the whole implementation still relies on those same three operations. Investing in a type system looks like a choice that compounds for the ecosystem over time: with the advent of AI agents, building more automatic correctness checks into the language looks like a solid bet. This is also tangentially related to the rediscovery of formal methods, now that a lot of that effort can be tackled with agents.

 Quinn Wilton's talks usually make me think deeply, and this one was no exception. In a rather unconventional talk, Quinn showed how AI can open up a whole new world of possibilities by letting builders hand off the parts they don't want to build to agents, so they can stay focused on the meat of the ideas they actually want to pursue. Basically, using AI to empower creativity by removing the most mechanical and boring parts of big ideas. She masterfully made this point while doing a deep dive into the history of climate prediction. I 100% recommend watching it.

 Chris McCord's keynote followed the thread he has been pulling on lately: pushing AI agents as far as they can go. Now that agents can run continuously, he showed how they have allowed him to take on ambitious projects that would have been hard to justify otherwise. Two examples he walked through are 

, an eventually consistent distributed process registry with process groups and lifecycle monitoring, and 

, which gives you GenServers that persist their state and survive node failures and deployments. Both were built to power Sprites at Fly.io, and both are the kind of infrastructure work that used to take a team, not a single person with agents at their disposal.

 in his keynote, Zach Daniel presented what he believes is the future of software development (at least for now). He sees AI as an exoskeleton rather than an autopilot, making the distinction that AI should empower humans, not replace them. Beyond making the argument, he showed what this exoskeleton looks like in practice, walking through different ways you can empower your development teams: from simple recipes like automated code reviews, to more complex things like building a "homebase" app that holds all the context a bot needs to help with team productivity, checking project status, or facilitating communication between teams working on the same part of the app. This one really hit home for me in terms of where to stand on AI use, and how to make the most of it professionally.

Let It Crash (But Not Everything). Strategic Supervision for Resilient Systems:

 Joe Harrow and Stephanie Lane gave an extensive introduction to supervision strategies using a live band as the running example, which was both hilarious and useful.

 Jacob Johnson presented and demoed an astronomy tool he built himself, written in Elixir, to explore data published by NASA. I thought it was really cool to see Elixir being used somewhere I wouldn't have expected at all.

Learnings from Building a Global Cluster at Supabase:

 probably my favorite from a technical point of view. Filipe Cabaço walked through the performance bottlenecks Supabase ran into while scaling their real-time service. The most interesting part is that the solution to all of their problems could be found within the ecosystem itself, and he gave examples of how he and his team are using the tools that are already out there, such as 

, among others. If you're working on highly scalable systems, this one is a must.

Dexter: An Elixir LSP Optimized for Large Codebases:

 Jesse Herrick told the story of the different eras of language servers at Remote, and how he ended up creating a language server himself that could handle a codebase as big as Remote's, which is potentially the largest Elixir codebase in the world. Besides the story, which is interesting on its own, he showcased Dexter's most important features. The talk was good enough to convince me to try Dexter in my dev environment. So far, no complaints!

Let Your Code Tell Its Story: Runtime Comprehension in Elixir:

 I expected this to be more of an experience-sharing talk, but I was pleasantly surprised to find out it was about a tool for getting better insight into systems at runtime. CodeStory is a dev tool that traces a span of execution and renders a nested call tree of your app's functions, with named arguments, values, and return values, so you can easily understand what's going on. I can see it being really useful when getting onboarded onto a new app!

I also presented this year, for the second time. My talk is available as a blog article here: 

The talk tackles the ongoing controversy around Phoenix contexts. They are often criticized for forcing Domain-Driven Design overhead onto small projects, but I argue the real problem isn't contexts themselves: it's the pressure to design domain boundaries upfront, precisely when you know the least about your domain. Instead, I propose starting with a single, deliberately coarse "god context" and letting real boundaries emerge through observation. The mental model is contexts as countries: boundaries should follow the natural divisions of the domain, and all traffic between contexts goes through a public "embassy" module that keeps each one sovereign over its schemas and behavior.

The practical part is a watchlist of signals that tell you when it's time to split a context (naming drift, the "and" test, border smuggling, test setup drag, and PR heatmaps) or to merge one, plus a step-by-step playbook for splitting safely in small, independent steps. The core idea is that structure amplifies whatever is already there: the same gravity that organizes code when you're paying attention turns into accretion when you're not.

A lot of the hallway track discussions I was part of were related to AI in some way. Some of them were very practical: which harness people were using, whether they were using agent swarms to get tasks done or something closer to pair programming. A lot of the technical discussions this year felt centered on how to verify software: how to do code review, whether to add more automated checks, or whether to lean on AI for this as well, using techniques like adversarial code review with multiple agents.

Other conversations were more existential: what the industry will look like in ten years, whether technical knowledge will still be relevant for doing development, or whether it will still make sense to pick a programming language to learn and become proficient at. I found that one particularly ironic given we were discussing it at a tech-specific conference, but we are living through a paradigm shift in the industry (if you're into philosophy, check out 

), so I expect this kind of thing to keep happening.

Another highlight of my trip was attending the Unconference organized by Dan Janowski, Director of Operations at the Erlang Ecosystem Foundation (EEF). We have been collaborating with the EEF for more than a year now, mostly helping out on the marketing side. Dan has been organizing these events as a lead-in to most of the conferences in the ecosystem. The format is very simple, and it basically lets attendees discuss whatever they feel matters most at the moment. Given the current state of affairs, it was impossible to avoid talking about AI, but we also covered other important, tangential topics: how to build community, what the future looks like for junior developers joining the ecosystem, and more. If you haven't attended one before, you should check it out.

If there was one theme running through this year's ElixirConf, it was AI. Not as a novelty anymore, but as something everyone is trying to figure out how to use well. The framing that stuck with me is Zach's: agents as an exoskeleton, not an autopilot. Hand off the mechanical parts, keep humans on the ideas and on verifying the results. It's also why José's bet on types feels right: the more code gets written by agents, the more valuable automatic correctness checks become.

It also answered, at least for me, the hallway question of whether picking a language still matters. Between Supabase scaling a global cluster with tools that already exist in the ecosystem and Dexter handling one of the largest Elixir codebases in the world, the answer is that the runtime and the community still give you a lot that no agent can.

We're heading home with a few things to dig into. First, I want to go deeper into how to use AI to empower team workflows, along the lines of what Zach presented: not just individual productivity, but tooling that helps the whole team stay in sync. Second, I want to take a closer look at formal verification. I took a course on it back in college and never thought I would actually need it professionally, but now that agents can take on most of the heavy lifting, it suddenly looks a lot more practical. And of course, we'll keep working with the EEF.

If you were at the conference and want to compare notes, or if you want to talk about Phoenix contexts, reach out. And if you've never been to ElixirConf, I hope to see you at the next one.

ElixirConf US 2026: What We Brought Home from Chicago

This article is the written version of my ElixirConf 2026 talk of the same name. 

There's a file I want to tell you about. 

 — 6,217 lines. Forty-plus public functions: 

... It's a real file; names changed to protect the guilty.

Nobody designed this file. Everybody built it.

If you've worked on a Phoenix app past its second year, there is a big chance you have this file too. And it has a strange property that took me a long time to see clearly: 

 The last 2,000 lines arrived twice as fast as the first 2,000. Growth wasn't linear — it was accelerating.

Hold that thought. We'll come back to it at the end.

. The argument: contexts, introduced in Phoenix 1.3, raised the barrier to entry and hurt adoption. The specific criticisms:

You're forced to name domains before requirements exist.

It's DDD overhead imposed on small projects.

The result is often thin wrappers of "dubious architectural benefit."

Contexts are "a consistent source of confusion" for beginners.

I want to concede something immediately and sincerely: 

every one of these criticisms describes real pain. I've felt all of them. The critics are right about the symptoms.

They're wrong about the diagnosis. This article is the alternative diagnosis.

First, let's be honest about what contexts are: convention, not law. Call 

 straight from your LiveView — nothing breaks. Plenty of apps ship this way.

But look at what assumes the convention: the 

. Phoenix 1.8's scopes (more on those later — they're the clincher). Every guide and tutorial. Your next teammate. Your next codebase.

Opting out doesn't make you wrong. It makes you alone. A codebase without contexts is an unrecognized state: functional internally, no diplomatic relations with the ecosystem.

The wrong diagnosis: it's not contexts, it's 

Here's the moment the critics are actually complaining about:

 — is a permanent architectural decision, demanded at the moment of maximum ignorance. You've written zero features. You've met zero real requirements. And the framework is asking you to draw a national border.

Notice what the critics and the DDD purists have in common: 

both assume boundaries are designed upfront.

 One says "do it rigorously," the other says "it hurts, remove it." Same wrong premise.

This is also why this is not a DDD article. Bounded contexts are the 

 of deep domain learning — upfront DDD asks you to do DDD's hardest step first, with the least information you'll ever have. (We'll steal exactly one thing from DDD later. It's the right thing to steal.)

So what's the pragmatic alternative? It's more radical than you'd expect:

For a new Phoenix app, don't invent domain boundaries on day one.

 Start with one coarse context — plus whatever 

 hands you — and let the real boundaries emerge. If boundaries are supposed to emerge, the god-context phase is 

But wait — didn't I open with a horror story about exactly this? Here's the distinction that matters: that 6,217-line file wasn't a failure of size. It was a failure of 

. Nobody was watching what the file was doing to every new feature decision.

You only get to skip the upfront modeling if you commit to watching the signals. That's the price.

A god context under watch is a starting point. A god context unattended is a 6,217-line file. The middle sections of this article are the watchlist.

One more reason to bias toward starting coarse: splitting later is cheap (I'll prove it with a playbook), but un-merging a wrongly guessed boundary is expensive. When in doubt, err big.

Before we can watch for boundaries, we need a working model of what one 

Within a country, provinces interact freely. 

 can know each other, share queries, skip the ceremony — that's domestic affairs.

. A province of one country doesn't negotiate with a province of another. There's a hierarchy, and it's respected.

. Structs may cross the border as read-only facts — that's idiomatic Phoenix, and 1.8's own 

 carries a user struct into everything. What never crosses: 

You can read another country's documents. You can't write in them, and you can't rummage through their filing cabinets.

 has no idea how refunds work — and it doesn't want to know. That's the whole embassy.

On the right: it compiles. Tests pass. It ships the same afternoon. And it's two violations, not one — the query is reading a foreign filing cabinet, and the update is 

 can no longer guarantee a single invariant about its own data.

The uncomfortable part is that the right side 

. Nobody stops you at this border. It keeps working right up until 

 changes how refunds are stored — refunds become their own table, or that status becomes a state machine — and on that day you find out three other countries had troops on that farm field.

One more thing the country metaphor gives us, and it's the thesis of this whole article. Look at a map. Borders drawn by committee, far from the territory, in straight lines — those are the ones with a century of conflict behind them. Borders that follow rivers, mountains, language — those hold.

Your domain has rivers. You can't see them on day one. You find them by watching the terrain.

Five signals that a context wants to split; two that contexts want to merge. Each has a name — use the names in code review. This is the diligence you signed up for when you took the god-context deal.

Nobody decided to create a Billing namespace. The language wore a track through the module on its own. When a non-generic prefix appears three or four times, the module is telling you its name. Listen.

Describe what the context does, out loud. Count the "and"s.

If you can't describe a context without "and," the sentence found the seam before you did. This one is cheap enough to run in a standup — no tooling required.

Who's reaching across the border without going through the embassy?

The heuristic is the capitalization after the dot. Lowercase means a function on the public module — legal embassy traffic. A capital letter means a schema or internal module — you're inside another country's territory. No hand-maintained exclusion list needed.

 reads and writes against another context's schemas mean ownership of the 

. And here's the productive way to read the results: where smuggling concentrates is exactly where the real border wants to be.

One function under test. Four contexts of setup.

Setup pain is coupling made visible. If testing one function requires assembling half the app, that function's context has half the app inside it.

If every feature, regardless of domain, touches the same file — that's not a popular file. That's a border dispute. There's a social version of this signal too: if every planning discussion ends with "eh, just put it in Events," your 

 is feeling the same pull the codebase is.

Splitting isn't the only move. Over-splitting is how "pragmatic contexts" becomes 37 microservices in a trenchcoat — and it's behind the critics' fairest complaint, the thin wrapper of dubious benefit. The answer to a pass-through context is merging it, not abolishing contexts. Watch for:

 — every operation in A needs three calls into B.

 — a context whose embassy just forwards paperwork.

The ceremony at the border is information. If two countries need an embassy call for everything, maybe they're one country.

Here's the playbook, and here's its one structural trick: 

every step ships independently, and the app works after each one.

 No six-week refactor branch that dies in review. No big-bang PR. Ever.

The new context starts as vocabulary, not code. Before any file moves, get the team saying "Billing" — in standups, in tickets, in PR titles. If the name doesn't stick in conversation, it won't stick in code.

This is the one thing we steal from DDD: 

 We're doing DDD backwards — evidence first, model second. Backwards is the direction that works.

The embassy opens before the border moves. This PR is zero-risk and ships today; the implementation hasn't moved an inch. But from this moment, every 

 piece of billing code has an obviously correct home — you get the benefit before the migration is even finished.

Step 3 — Migrate callers, then move behavior — 

Callers switch to the new name, one mechanical PR per calling area (the web layer, each other context, the tests). Then function bodies move from 

 — the schema — stays put. This is where most refactors stall: teams think the split isn't real until schemas move. 

 Decouple "who owns the code path" from "who owns the table."

 touches every alias, every query, every changeset, every factory, and — worst of all — every 

 contexts. A schema move structurally wants to be a big-bang PR, the exact thing this playbook exists to avoid.

Behavior ownership is the real coupling. Once every read and write goes through 

, the file's physical location is nearly cosmetic. Schema relocation is the 

 step of a split — a cheap, mechanical rename once all callers are migrated — and never the measure of progress. (The database table never needs renaming at all.)

Deprecation makes stragglers surface in CI gently. Also won't stop moving forward if you absolutely need a temporal exception.

First you draw the border. Then you staff it. The 

 library promotes the border from honor system to law — illegal crossings become 

mix xref graph --sink lib/ticket_hub/billing.ex

 shows you the smuggling routes today, for free. This is also the step that retires the Signal 3 grep: once the border is compiler-enforced, you stop needing to police it by hand.

Phoenix 1.8 staffs the border for you: scopes

If you still think of contexts as a style choice, Phoenix 1.8 should change your mind. The generators now pass a 

 — current user, org, permissions — as the 

The scope is a passport: every border crossing gets identity-checked. The target is broken access control — OWASP's #1 web application risk.

Here's the point that matters for this article: 

scopes only work because the embassy is the single chokepoint.

 directly, there is no checkpoint — no single place to enforce who may see what.

Phoenix Contexts in the Real World: From Theory to Survival

Whether it’s a large Phoenix application or a smaller service running only Plug and a couple of routes, background jobs are usually part of the stack. Oban has been rock solid for us for years.

One thing we also really like is Oban Web. It gives you visibility into your queues, workers, retries, failures, and everything else you need to understand what your jobs are doing.

That’s completely reasonable — Oban Web is built for Phoenix applications and integrates beautifully there. But not every project we build needs the full Phoenix stack.

At Mimiquate, some of our internal tools and smaller services are just Mix applications with Plug for a simple UI. In those projects, pulling Phoenix just to get a jobs dashboard felt unnecessary.

 a way to run Oban Web as a standalone application, and it works great too. But that means another application to deploy, configure, and maintain.

Ocelot is a lightweight dashboard for Oban.

Understand what’s happening in your background processing system

No job controls. No advanced management features. No attempt to replace Oban Web.

The goal is simply to provide visibility for projects that don’t use Phoenix and don’t want the operational overhead of running a separate dashboard application.

Right now, Ocelot focuses mostly on visibility.

That wasn’t really a philosophical decision as much as a practical one.

When we started building it, the immediate need was simply understanding what was happening inside our queues.

Most of the time, when debugging or monitoring smaller systems, we just wanted to answer questions like:

So the first version focused on making those answers easy to access while keeping the implementation small and straightforward.

Over time, we’ll probably add actions and more management capabilities as we need them ourselves.

But for now, keeping the scope focused has worked well.

One thing we’ve learned over time is that smaller Elixir applications benefit a lot from staying small.

Sometimes a Plug application with a couple of routes is all you need.

Adding Phoenix just for one dashboard page can feel like a lot of extra surface area — especially if the rest of the application is intentionally lightweight.

Mimiquate Blog

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

10 Years of Mimiquate: What We’ve Learned and What Comes Next

ElixirConf US 2026: What We Brought Home from Chicago

Phoenix Contexts in the Real World: From Theory to Survival

Introducing Ocelot: A Lightweight Oban Dashboard Without Phoenix

Designing AI Features That Actually Help Users

How ProcessTree Saved My Async Tests

Fun with Ecto Types

Mimiquate at ElixirConf 2025 & open source updates

Introducing Elixir Observer: A Better Way to Explore Elixir Packages

Test Your Elixir Package Against Different Versions of Its Dependencies

Tower: Universal and Agnostic Elixir Exception Tracker

Mimiquate's New Look and Blog

Recap ElixirConf 2024