aimee ault
☾ dark
Aimee in pink sunglasses, smiling, in a sunlit forest
[ About me ]

I'm Aimee.

I'm a software architect by day, a writer, runner, sewist, xenolinguist, traveler, woodworker, and parent by night. Since 2004, I've been deconstructing overly complex systems purely out of my own intolerance for things that lack coherence 😂

I'm deeply passionate about staying close to the user experience of systems I work in. A coworker recently referred to me as "the people's architect," and that honestly is everything I've ever aspired for, doing what's right in the most thoughtful manner.

Sometimes I write about my experiences. I like to tell stories with diagrams, sometimes with code, sometimes as optimistic manifestos about beautiful things I want to see happen.

stack /things i actually use

technologies
Ruby, Elixir, Postgres, Phoenix, Rails, AWS, event-driven systems and Kafka streaming, GraphQL, Elasticsearch/Opensearch, Redis, React + Typescript, NextJS (I'm generally tech stack agnostic, these are just the things I work with lately!)
editor
VSCode
AI
Skilled with most LLMs, Nano banana and other similar generative content platforms, I've rolled my own RAG solutions, MCP integrations, cloud agent automations, and I dabble in machine learning and vector embedding models on the side for fun.

operating principles /the rules

  1. Truth over comfort. If data shows something uncomfortable, that's interesting and worth exploring. Systems that lie to you, whether they're dashboards, metrics, or tools that tell you what you want to hear, are worse than no system at all.
  2. If it doesn't make sense as a user, it doesn't make sense. No amount of architectural elegance saves a feature that means nothing or is not clear in what its intent is.
  3. Respect what you're modeling. Whether it's a person, a relationship, a pattern, the thing you're representing is not just a schema or a contract. It's a part of a story you're building.
  4. The right abstraction is the most important thing you can do. Get the shapes wrong early and you'll spend years building around it. Get it right and everything downstream gets easier in ways you can't predict yet. This requires more than just technical foresight. Half of it is just reading the unspoken vibes of the people telling you what they want.
  5. Establish your domains early. The boundaries you draw in the first few weeks become the boundaries the team thinks in for years. That's foundational, not refactorable, foundational.
  6. Ship, show, iterate. Nobody funds a design doc. Nobody believes a roadmap. If you want buy-in, put something in front of people and let them react to it. Then do it again.
  7. Prototype Nobody has to give you permission to build something. If you want to make a case, sometimes just building the damn thing is the thing that does it.

say hi /contact

I'm findable on these platforms!

Github LinkedIn