Home / About the author

The person behind the product

Jimenez Julien

Founder of AisleTimeline and publication director at MLJ, SASU. He writes the product, the documentation and every word on this site.

Portrait of Jimenez Julien

Jimenez Julien, founder, AisleTimeline

  • Publication director, MLJ, SASU
  • Building software for service trades since 2016
  • Writes every release note on this product

Why I built a run of show tool

I did not come to weddings from the inside. I came to them the way most software people do, through a friend who was drowning. In the spring of 2021 a coordinator I have known for years asked me to look at her Friday routine, because she was losing entire evenings to it and could not work out why. What she showed me was a word processing document with a table in it, thirty eight rows deep, that she had rebuilt nine times for one Saturday in June. Each rebuild produced a PDF. Each PDF went out to between eleven and sixteen vendors. When a start time moved, the whole ritual began again, and she had no way of knowing whether the videographer had opened version six or version nine.

That is not a document problem. It is a distribution problem wearing a document costume. The information she needed to move around was small: who arrives when, what happens next, who needs to hear that something changed. The reason it took her hours was that the format she was using could not tell one vendor from another, could not tell what had changed, and could not tell her who had read it. So I spent that summer sitting in on final walkthroughs and standing at the back of receptions with a notebook, and I built the first version of AisleTimeline for exactly one planner and eleven of her vendors.

What I learned about this trade

The first thing I got wrong was thinking planners wanted a project management tool. They do not. A wedding is not a project with a backlog, it is a live performance with a curtain time, and the software has to behave accordingly. The second thing I got wrong was assuming vendors would create accounts. They will not, and they are right not to. A florist working four weddings a weekend is not going to hold four passwords for four planners. Everything that touches a vendor in this product opens from a link, in a browser, with no sign in, because that is the only shape that survives contact with a real Saturday.

The third lesson took two full seasons. Planners do not fear change, they fear unlogged change. The moment a coordinator can point at a record showing that the 4:15 shift went out at 2:07 p.m. and was opened by the caterer at 2:09, the entire emotional weight of the job drops. That is why confirmation tracking is not a premium extra bolted on the side. It is the reason the rest of the product holds together.

I also learned that this trade speaks precisely. A flip is not a turnover. A call time is not an arrival time. Vendor meals have a place in the run of show and getting that place wrong makes a catering captain hate you. When we write labels inside the product, we use the words coordinators already use, and when a term differs between the Northeast and the Gulf Coast we let the account choose.

Experience and expertise

I have spent the last decade building operational software for trades that run on appointments and hard deadlines, and I keep coming back to the same pattern: the bottleneck is almost never the work itself, it is the retelling of the work to everyone else who needs it. Before AisleTimeline I built scheduling and dispatch tooling for field service teams, which taught me how to design for people who are holding a phone in one hand and a clipboard in the other, outdoors, with poor signal and no patience.

For this product specifically, I have observed 74 wedding days from load-in to strike across nine states, sat in on more than 200 hours of final walkthroughs and vendor calls, and read every support ticket AisleTimeline has ever received. I run a standing monthly call with a group of twelve planners, from solo day of coordinators to a Chicago agency running four teams, and they see roadmap decisions before anyone else does.

How this product is built and maintained

The rule I work to is simple: nothing ships into the product unless a working coordinator has used it on a real event. Features are tested in season, on live weddings, with planners who have agreed to be the first to try them and who can turn them off mid day if they get in the way. We ship on Tuesday mornings and never between Thursday and Sunday during peak season, because pushing code at a planner on a wedding weekend is an unforced error.

Editorially I hold this site to the same standard. Every number on these pages comes from either our own event records or from an anonymized data share that 612 planning businesses opted into, and every one of them is a median rather than a highlight. Testimonials are published with the full name, role, business and city of a real customer who read and approved the quote. When a figure changes, the page changes, and the last updated date on the legal pages moves with it. No stock claims, no borrowed statistics, no invented awards.

I am accountable for all of it. I write the copy, I set the pricing, I answer support during peak season alongside the team, and if a change notice fails to reach a vendor on a Saturday, that failure is mine to explain. My name is on the publication director line of the legal notice for that reason and not as a formality.

Published articles

Everything I write for planners and day of coordinators is published in Run of Show, the AisleTimeline magazine, and these nine pieces went out together on the day the magazine opened.

Contact the author

Write to me directly at jimenezjulien42@gmail.com. I read everything, including the messages that begin with a complaint. If you want to talk about the product itself, the fastest route is the demo request form, which lands in the same inbox with a little more context attached. Planners who want to join the monthly roadmap call can say so in either place.

Find me elsewhere