The Single Profile Problem

I filled out a conference registration form last spring and got to the bio field, the one that always asks for two to three sentences about yourself, and realized I had typed almost the same paragraph into a form three weeks earlier for a different event. Same job title, same two sentences about what I work on, same list of interests, reworded slightly because I couldn't remember exactly what I'd written the first time. Nothing about that data had changed. Only the form had.

If you organize or attend NOG events with any regularity, this is just background noise. Registration wants your bio and affiliation. The CfP tool wants a slightly longer version plus a headshot. The meeting scheduler wants your interests again, phrased as topics instead of a paragraph. Badge printing wants your name and company, capitalized however you feel like capitalizing it that day. Four tools, one person, the same six facts typed in four times with four small inconsistencies.

NOGnet is the event-support platform I build for NOG organizers, solo, in the hours before and after a day job. It grew out of about three years of earlier event-tooling work, spreadsheets, one-off scripts, small internal tools I built for organizers who needed something and didn't have a vendor for it. Watching the same people re-enter the same information at every stop of an event cycle is where this particular itch came from.

Where the profile actually lives

Most event software puts the event at the center of the data model. You register, and a row gets created that ties your name, bio, and company to that specific event. Submit a CfP for a different event on the same platform and you're creating another row, because the schema assumes an attendee record only makes sense in the context of one event.

NOGnet flips which object is the root. The profile exists on its own, independent of any single event, and registration, CfP submission, and meeting scheduling are all just modules that reference it. Update your bio once and it's current in the CfP tool, the attendee directory, and next month's registration form without you touching any of them again. It sounds like a small reversal. In practice it meant redesigning the schema before I wrote a line of the registration flow, because retrofitting a shared profile onto four modules that already assume they own their own copy of your data is much worse than deciding it up front.

Where it got harder than the pitch

The reuse part was the easy half. The harder half was visibility, not everything on your profile should follow you to every event. Someone might want their full bio and company on a CfP submission and only a first name on a public attendee list. That meant building per-field, per-context visibility rules instead of a single public/private toggle, which took longer than the reusable-object idea itself and honestly still isn't somewhere I'd call finished.

There's also the harder question I don't have a clean answer to yet: how much should a profile remember across years of events versus how much should quietly age out if nobody touches it. I've landed on "let people edit and delete freely, default to less retained rather than more," but that's a policy decision dressed up as a technical one, and I revisit it more often than I'd like to admit.

For now the practical win is smaller and more boring than any of that: I haven't had to retype my own bio in months, and neither has anyone who's used the platform for more than one event. That's the whole feature, really. Not clever, just one less form.