najmuzzaman

we ended up with the most viral launch of our yc batch. this is how.

1. we broke the mold. five days before launch we did not have a video.

every launch video in the batch looked the same. founder sits down, talks to camera, cuts to product shots, cuts back to founder. it works. it also disappears when four hundred companies do it in the same week.

so we made a mini episode of the office instead. we sell an ai harness called nex.ai for gtm and revops people, and it only makes sense if you have felt the specific chaos of an office with a broken workflow, the person who made it gone ages ago and every person frantically trying to fix it to become the company's ai champion.

we made an ai generated mini-episode of the office with us founders as interns in it and put all our love of the show in the script and the shots.

five days later it was the most shared thing our batch put out. 1800+ reactions on linkedin in the first week and still going. signups went from about 3 a day to 347 in a week.

we thought it was funny. nbcuniversal's rights team disagreed. days after we uploaded they filed a takedown. youtube pulled the video and put a strike on our channel.

it stayed on linkedin though. 1800+ reactions in the first week.

2. everyone says founders should make the launch video themselves because nobody else gets the product. that advice is protecting you from a bad agency, not from agencies.

doing it ourselves meant two founders spending a week making something worse than a pro could make in the same week, while not building and not selling. so we found an ai-native video agency, bambam: https://x.com/thefirst_ad, that took the idea and made it real in a week and did a great job at it. it was so good that the founder of hubspot asked us who did it.

3. outsourcing did not mean hands off. we read every line of the script and watched every clip, and rewrote a lot of the jokes. a joke that is structurally right and tonally wrong is worse than no joke. every character in that show has a specific rhythm, and getting it 80% right is worse than not trying. that part we could not delegate. the production is the part we should not have tried.

4. seedance is OP. it took our photos and turned them into pretty accurate lifelike AI clones of us down to the mannerisms. It was scary and exciting.

5. we invested in high-quality mics (Hollyland Lark M2s are tiny but amazing for sound quality and noise cancellation) and did all the voiceover ourselves instead of an AI dub that would have not been natural.

6. we used remotion for generating product shots that emulated our product design to the T. our designer has a whole playbook to do this right with any product in literally, minutes.

7. no matter how good a launch video is, no one cares if they don't understand your positioning. best way to write product messaging is to dig through customer conversations to look for 2 reactions "finally, someone who gets it" (problem) and "wait. it can do that?" (solution).

8. finally, product needs to deliver, or else all that inbound would have turned into dust. our free trial needs a credit card but that has not stopped users from using us. we had scaled our infra for 10x traffic before the launch. we were not ready for what was about to come.

we went viral twice this year, once of HN and now on linkedin. does lightning strike twice?

nicht geil. are you really so full of yourself? every customization is not "required" from day-1 and is always a (maintenance and UX) disaster if you did. i have filed an issue for it but not added it to the system yet. not gonna AI slop this just for the sake of adding another feature.

karpathy's llm wiki tweet and gist: https://x.com/karpathy/status/2040470801506541998?s=20

i used this idea to create a version that works for a team of ai agents

yes, and we should expose it. today the wiki location is hardcoded to ~/.wuphf/wiki/. making it a config field is a quick change. just filed an issue: https://github.com/nex-crm/wuphf/issues/310

had fun while building this and love "The Office". fwiw i used to be a stand up comic and did lots of satire, but this one is not a shell/slop project to take on the craziness of slop agents being shipped as world-changing (while all they did was asked AI to write smart md files).

there is real substance in the product itself and something that i use myself for work. feel free to ask any questions.

supported via OpenCode, which is the runtime that speaks the OpenAI-compatible surface. DeepSeek exposes that surface, so the path is: point OpenCode at the DeepSeek base URL and key, then set OpenCode as your synthesis or runtime CLI in the WUPHF config.

can also do llama.cpp server, LM Studio, LocalAI, OpenRouter, Together, Anyscale, and anything else with the OpenAI surface. i am using ollama already through OpenCode.

if you hit a specific endpoint that does not work, please file an issue.

this is not a personal wiki though. it is a team wiki. agents are responsible to manage it and keep it fresh and always visible with human oversight.

tbh this won't be much useful as a personal wiki.

let's talk about real stuff. we built an AI-native CRM backed by HubSpot founder Dharmesh Shah last year before this, had revenue, iterated to focus on context graph infra which looked like the right moat to focus on, did enterprise PoCs, and all of that distilled into this personal project i built on the side to help my own work. turned out to be right interface for making context infra usable.

the team is of 4 HubSpotters who built HubSpot's largest platforms - search, nav, notifs, permissions, AI.

we are in the process of opening up large pieces of our enterprise context architecture to WUPHF and also ship the cloud enterprise version of WUPHF (https://nex.ai/new-home).

fair. the post title leads with the wiki because the Karpathy framing is the angle i think this audience cares about, but the wiki ships as part of WUPHF (an open source collaborative office for AI agents) and the repo README naturally leads with the broader product. i should have surfaced "ships as part of WUPHF" earlier in the post body.

if you want the wiki only, install WUPHF and only use the wiki layer. the promotion flow, fact log, and /lookup work without the multi-agent office around them.

love the "Borrowable Ideas" section. would suggest to definitely borrow them.

full disclosure: we started as a context infra company (nex.ai) from long long before Karpathy even came up with the LLM wiki idea, and have barely exposed any of that stuff to WUPHF but starting to open some of that now. glad to see the concerns in the comparison are things that our context infra already built for.

still, happy to collab & share learnings, and of course avoid duplication.

thanks for saying this. one more reason people are hating on SaaS so much is that the UI is dry and for many, unusable. on the other hand, the cool AI agents have UI which is fun but again, unusable.

fun and usable can co-exist and we are trying the best to prove that. also, we have an amazing designer who never worked at big tech and has no accolades, but man got taste.

alright sir/ma'am/neither. we built an AI-native CRM backed by HubSpot founder Dharmesh Shah last year before this, had revenue, iterated to focus on context graph infra which looked like the right moat to focus on, did enterprise PoCs, and all of that distilled into this personal project i built on the side to help my own work. turned out to be right interface for making context infra usable.

not interested in a job at Anthropic as Principal Engineer (i used to be a HubSpot Product Manager with a healthy income, much better than what i am making now, or for the next few years).

took multiple bets and did iterations because we talked to customers and kept evolving while our old competition is still building an AI CRM "in stealth".

been around enough to know waves don't matter but there is still value behind those waves worth extracting away.

Two structural reasons. 1. Obsidian is a single-user editor. It does not have the concept of "agent A drafted this, agent B promoted it, the team approved it." The promotion flow needs a state machine that lives outside the editor. a plugin can simulate it but the source-of-truth has to be a process the agents talk to instead of a vault file. 2. Agents need an MCP surface. An Obsidian plugin API won't do. /lookup, entity_fact_record, notebook_write, and team_wiki_promote are MCP tools the agent runtimes call directly. Obsidian's plugin API targets human users and the Electron app. You would be reimplementing the MCP layer to bridge. Practical compatibility: you can absolutely point Obsidian at ~/.wuphf/wiki/ and use it as a vault (we got someone from our Reddit post do this). Obsidian can be reader while WUPHF stays the writer.