I worked like the company was mine. Here is what two and a half years at a Silicon Valley startup taught me.

Ray Thurn Void — Sun, 18 Oct 2026 11:46:10 +0000

I was a frontend engineer at Sybill from May 2024 to September 2026.

Founders do not wait for a ticket. For two and a half years, neither did I.

In May 2024 I joined Sybill, a Silicon Valley startup that builds AI for sales teams. I was hired as a frontend engineer. Over the next two and a half years I built a large part of Ask Sybill, our AI chat, from its first version to the day I left. A strong backend team built the AI brain behind it. My job was everything around that brain, so that people enjoyed using it every day.

If something hurt our users or the company, I treated it as my problem, even when nobody had put it on my list. This is the story of what that looked like, day by day.

My GitHub stats from my last two years at Sybill.

It started on day one

On my first day, the browser's developer tools were slow on our app. I wanted to know why. The cause was in our CSS: the same block of style values was copied into the page again and again, once for every file that used it. I removed the copies, the app shipped less CSS, and the tools were fast again. Nobody had asked me to look.

In my first week I moved our build to Vite, a much faster build tool, and a few days later the tests followed. I pushed the team toward TypeScript, which catches mistakes before the code runs, and I started refactoring right away. I did it because I cared about the software we all worked in every day. If the floor creaks, you fix it today.

I gave every screen the same building blocks

Six months in, I noticed that every screen in our app had built its own buttons, modals and menus. Some existed twice. Most of them I would not have approved in a code review. So every new feature started by building the same basic pieces again.

AI could not help much with this yet. When I joined, we used GitHub Copilot in VS Code, and it mostly finished the line you were typing. Then we moved to Cursor with Sonnet 3.5, and its Composer, a chat window that could edit code for you, felt like a huge jump. It could write a function. It could not write good UI that matched the rest of our app.

The old way to go faster was to reuse code. In a product like ours, most screens have to be made for their own job, so you cannot share much of the high-level code. But the small pieces can be shared. A button, a modal and a menu should work the same everywhere.

A Sybill app screen. Buttons, menus and chips like these are the small pieces a shared library gives every screen.

I had wanted a component library for months, so when our CTO mentioned the idea, I was ready. In December 2024 I created syb-ui. I built it with the compound components pattern before I even knew the pattern had a name. It just felt like the natural way to do it. It was also not my first time. I had built component libraries twice before, both in Svelte: once as an open-source side project I never finished, and once at work at Altice.

It paid off. The UI became consistent, we had fewer UI bugs, and new screens were faster to build because we could take an existing screen as a reference. For months I was the only one working on it. Then other engineers started adding to it, and it became a team effort. To me, that was the real sign it worked.

We built an AI chat before the tools for it existed

In January 2025 we started Ask Sybill. Today there are popular frameworks for building an AI chat. Back then they were young and few teams used them, so we built it all ourselves: answers that stream in word by word, a stop button, retries, and a way to manage the huge amount of state an AI chat needs to work.

Sybill's AI agent answering a user query.

For months, almost the whole chat lived in one file. By September 2025 it was about 4,800 lines long. Most people would tell you to split a file like that early. I chose not to. One file kept the total amount of code small, and there were no layers to dig through to understand one click.

It also helped in a way I did not plan. For most of 2025, AI tools did not get much better. Anthropic's models were the best we had. The most expensive models, like Opus and OpenAI's o1 and o3, cost a lot and were not worth it for our daily work. With tools that weak, one big file was a gift: the AI could see everything important in one place. A big file is fine. A big file nobody understands is not.

The right moment to split came when we put Ask Sybill in a sidebar too. The core of the chat moved into one shared piece that both screens used. Each screen kept its own wiring, the code that connects that core to its buttons and lists. About 70% of the two screens behaved the same, but the other 30% had to be different, because the screens did different jobs. With separate wiring, neither screen could break the other. I only connect two parts of the code when the product connects them.

From there, the chat grew up with the rest of the market. At the start, every AI chat was simple: you ask, it answers. Then they learned to run many conversations at once, keep working in the background and use outside tools. Ask Sybill followed the same path. I started with the simplest design that worked and made it more advanced only when the product needed it. The models grew up too. GPT 5 was the first GPT model I really liked, and later Opus 4.5 was another big step.

To keep up, I improved the code all the time. Every time I touched a part of the app, I tried to leave it faster and simpler than I found it. I was known for two things: making the product better, and breaking some of it on the way. During one big refactor of the AI chat, I introduced bugs. I knew it could happen. Refactoring is risky and nobody thanks you for it: when it works, nobody notices, and when it breaks, everybody does. I did it anyway, because I knew what I was doing and better software is worth the risk.

I never let slow or broken things slide

I used our product every day and watched it closely. I watched session recordings of real users and checked our metrics. This was never perfect. We always had more work than time, so these fixes came in small steps, whenever I had a chance. But when something was slow or broken, I did not wait for it to reach the roadmap.

Long chats are a good example. Very few users had them, but for those few, opening a long chat could freeze the app for about 20 seconds. They just stared at the greeting screen, wondering if anything was happening. The code made it clear that this would only get worse as people used the chat more, and I do not like leaving edge cases like that open.

The usual answer is virtualization: draw only the messages you can see on the screen. Virtualization is a fine tool, but it brings its own problems, and I like to understand the root cause first, in code and in life. So I went through the code one function at a time and made each one faster, to raise our baseline. My rule is simple: make the code truly fast first, and add virtualization only when you reach a size where nothing else works.

Then I brainstormed with GPT 6 Astra, and it came up with a clever use of a React feature called startTransition. React uses it to mark an update as not urgent, so the screen stays responsive, for example while you switch tabs. We used it to build a long chat in small pieces: the newest messages show up at once, and the older ones are added quietly in the background. That one idea did about 80% of the job. The freeze went from about 20 seconds to about 1.4 seconds.

Opening a very long chat: newest messages first, older ones in the background.

I thought about the product, not only the code

Fixing what is slow is engineering. Deciding what to build is product. Any product that wants to be good needs both.

Users kept telling us that cutting video clips from their recorded meetings was painful. It took too many steps, it was not clear what to click, and sometimes people lost their work. It was not on the roadmap, and nobody asked me to fix it. So I watched the recordings, read the feedback and designed a new page myself. For ideas, I looked at classic video editors like Sony Vegas, with a real timeline where you can see and shape every clip. Our designer polished the look, and I shipped it. Customers praised it to me directly. That story gets its own article.

We had also wanted, for a long time, to let Ask Sybill build small apps, like dashboards, that run right in the user's browser. That is powerful, but risky: the AI writes code, and that code runs on the user's screen. Our first version was very naive. I started a new project for it, and with a teammate I studied how Claude runs the code it writes. I already had some ideas of my own. In the end we built a sandbox that keeps the code safe and still lets the AI do useful work. For the dashboards we picked shadcn/ui instead of our own library, because Claude already writes it well without any guidance.

I worked on the company, not only in it

We were always running. There was always more to build than time to build it, so I guarded time like money. Every minute lost to bureaucracy or a meeting with no clear point was a minute we paid back at night or on the weekend.

That is why I pushed to keep our processes lean, and sometimes to have almost no process at all. The biggest waste I saw was the distance from our customers. There were too many steps between a customer and an engineer. Feedback got lost on the way, and people forgot how customers really felt. We were fast compared to many companies, but we could be faster. I wanted a key customer to ask for something and get it in one or two days.

So I pushed engineers to talk with customers directly in Slack, to ask the sales team what they were hearing, and to look at the analytics themselves. When one customer asked to sort their data in a new way, we shipped it in a day. That push was mostly mine, and I was still at it when I left.

Saving money was part of the same work. Our end-to-end tests had been broken for six months and still cost about $200 a month to run. We paid about $1,000 a month to store large files in our build pipeline that we did not need. And we sent so much useless noise to Sentry, our error tracking tool, that it cost about another $1,000 a month. Together that is more than $26,000 a year spent on nothing. None of it was my job. If the company were mine, I would want someone to fix it, so I fixed it.

I pushed AI everywhere (when it made sense)

I never treated AI like a religion. Online, the hype was loud long before the tools were good, and I did not let it move me. I watched the tools instead. Each time they got better, I noticed early and put them to work.

In the beginning, AI was only a small help. Still, in September 2024, a few months after I joined, I wrote our first rules file for AI tools: a short guide that tells the AI how we write code. Later I added skills, short guides for specific tasks. With them, anyone could quickly understand a complex component, or take a piece of existing code and turn it into new UI much faster.

Over time, more of the work became agentic, which means AI agents doing whole tasks on their own. We used them for debugging, performance profiling and analytics, and even to click through the app in a real browser to test it.

I pushed AI into places few teams had tried yet. I used it for handoffs and documentation, and I even added an AI step to our hiring process. I said it all the time: documentation is not for people, it is for AI. People rarely read docs. AI reads every word, and then it explains the code to people when they ask.

Then Fable 5 arrived, and my output roughly doubled. For the first time I was not buried in frontend work and tech debt, so I finally had time for the backend too. When a feature needed a backend change, I made it myself instead of waiting. As a team, we moved faster than the roadmap, which left room for the work nobody had planned.

What I would do differently

The first thing is people. There were moments of stress and frustration that could have been fun, with more frank and friendly talk. Today I try to let people be the main character of their own work. I cheer their choices even when I do not agree, and I put being welcoming before being right. It worked with some people and not with others. With some teammates it grew into a strong bond that made both of us happier and more productive, and that is one of the things I am proudest of. What I learned is that it has to start on day one.

The second is tests. I would not have spent time on end-to-end tests, the tests that click through the whole app like a real user. For a long time they did not pay off. They took a long time to write and run, and they kept breaking while the product changed every week. Nobody wanted to take time from features to fix them, so ours sat broken. Fable 5 changed that. It writes a decent test from a short description, so a new test costs almost nothing, and tests that were never worth it suddenly are. Another team brought them back.

The third is cleanup. In August 2026 we spent a week as a team deleting dead code. With Fable 5 we removed a lot of unused code. We tested everything ourselves, and no production issue showed up for a long time after. Still, I think cleanup belongs in every change. A special cleanup week teaches people to wait for the next one.

I left Sybill in September 2026. The lesson I take with me is simple:

Act like the company is yours, even when your title says otherwise.

This is me.

DEV Community: Ray Thurn Void