At two in the morning in San Francisco, Ai Daniil Bekirov had three Claude Code sessions running on his second monitor. A few months earlier, he had expected to graduate from University College London. His relatives had urged him to finish the degree and put the startup ambitions aside. Now he was announcing Sparkles, the company he had left university to build, and offering to onboard its first curious users himself.
The late hour makes a convenient opening scene. The more revealing detail comes a little further into his account: many of his friends were not technical. When they worked with developers, they felt stuck, waiting for someone else to move a project forward. Bekirov had found a way to accelerate his own working life. His business would try to give other people some of that freedom.
There is something pleasantly specific about this ambition. It begins with a colleague who knows what needs changing and cannot quite reach the controls. A button, a page, a task that requires another person's attention. Sparkles puts that everyday handoff at the center of its proposition.
The weekend that changed the timetable
Bekirov describes leaving university as a journey. Hackathons helped him see that he could make things, and that evidence mattered more to him than the abstract possibility of becoming a founder. The pace of building began to compete with the pace of lectures. His decision grew out of that comparison.
His early projects have the variety of someone trying doors. In October 2024, he submitted Notd to the Mistral AI London Hackathon. The idea was to scan notes and turn them into text-to-speech videos on YouTube, giving students another way to use their study material. The project listed HTML, CSS and Python among its ingredients.
By May 2025, he and Danila Kozlov had made GetShiftDone, a Chrome extension with considerably less patience for distraction. Its premise: detect wandering browser habits, then call someone who could deliver a motivational interruption. Productivity software rarely admits that its imagined customer might require a telephone intervention. This one made the embarrassment part of the pitch.
Neither project needs to be treated as a prophecy of Sparkles. They show a builder experimenting with interfaces, everyday friction and a joke that might make someone try the thing. A hackathon gives an idea a deadline. It also gives its maker something a lecture cannot always supply immediately: a working object to argue about.
Learning inside someone else's startup
Before Sparkles, Bekirov worked at Iterate and Structured AI. His personal site describes the first position as a software engineering internship and the second as software engineering. It also lists a Cursor ambassador role. The collection puts him close to the tools and teams whose working habits would become the subject of his own company.
Iterate was founded by Jonas Templestein, previously Monzo's co-founder and CTO. For a student considering his next move, that is a useful place to observe how experienced builders make decisions. Bekirov speaks warmly about the work and the people, then describes returning to university after that experience and finding the lecture hall difficult to accept.
He did not present the choice as a recommendation that everyone leave their course. He said university works well for some people, while he wanted to learn faster. That distinction gives his account its practical character. He was comparing environments he had actually tried, measuring them against what he wanted to do next.
“It doesn’t happen like that - it was a journey.”
Ai Daniil Bekirov, on leaving UCL
The application to Y Combinator arrived late. He recalls applying at the deadline and changing direction the day before his interview. Getting accepted did not require a perfectly straight account of what he would build. It required him to explain the direction he was taking at that moment.
The customer hiding inside the developer tool
One earlier idea involved taking context from a screen and passing it to other applications. Bekirov intended it as a developer tool. During onboarding, he began hearing responses that pointed him toward another user and another problem. The encounters helped him reconsider who should be able to operate the software.
That is a small but consequential adjustment. A product can become more interesting when its maker notices the person standing just outside the original audience. The engineer may understand the setup. The colleague beside them may have the change in mind. Making the second person wait for the first becomes the problem worth examining.
Bekirov's description of YC is similarly practical. He values being around other people building companies and having partners available for support. Asked about hidden knowledge, he points toward the material YC already puts on YouTube. He seems more interested in the working environment than in a secret password to entrepreneurship.
There is a useful restraint in that account. The accelerator supplies people, conversations and an opportunity to keep building. The founder still has to decide what the customer meant, which problem to pursue and what to make next. Those decisions remain his job.
Sharon gets a pull request
Sparkles introduces its imagined user as Sharon, a colleague in marketing or operations who wants to change button styling on a live product. The modesty of the example is part of its usefulness. Sharon does not need a manifesto about the future of software. She needs the button changed.
The workflow begins with someone technical connecting GitHub and configuring the repository and environment. Colleagues can then work through a browser interface, describe changes and see a preview. Uploading a change creates a pull request for an engineer to review. The product moves the starting point closer to the person requesting the work.
- 01Connect the repositoryTechnical setup
- 02Describe the changeTeammate + AI
- 03Look at the previewSee what changed
- 04Review the pull requestEngineer checks the work
For Bekirov, the existing project is the important setting. A company's software already has conventions and people responsible for it. Letting another colleague propose an edit raises questions about review as well as convenience. The engineer's place in the process helps explain why the pull request matters.
It is an appealingly unglamorous unit of progress: a proposed change that someone can inspect. Behind the cheerful company name sits the ordinary business of teams agreeing on what should enter their codebase.
A fundraising announcement, with reservations
On May 28, 2026, Bekirov turned 21. The day before, he wrote, he had sent an offer to his first hire for more than twice what he had earned a year earlier. He also said Sparkles had raised $3.5 million. The birthday comparison gives the funding figure a human scale: he had moved from receiving an internship opportunity to offering a job.
He called the occasion a checkpoint, while acknowledging that meaningful success still lay ahead. The wording is sensible. Money lets a company attempt more work. A first offer changes its obligations. Neither settles whether customers will keep using what it builds.
In another interview, Bekirov argued that fundraising announcements can distract founders from their own progress. He treats raising capital and building a company as separate activities, each with its own demands. The applause attached to a round can be considerably easier to recognize than the quality of the work it finances.
That skepticism is interesting coming from someone whose company has backing. It gives the number a place in the story without allowing it to take over. The next useful question concerns what the team can make with the time and people it buys.
Even the Wi-Fi is raising a seed round
Bekirov's account of early marketing contains a joke that hardly needed improving. In a San Francisco building popular with YC founders, he went looking for a Wi-Fi password and saw a network named for a $2 million seed raise at a $25 million cap. Startup conversation had escaped the living room and entered the router.
He posted the discovery on X and said it drew roughly 10,000 views overnight. People seeing the post could notice the Sparkles name beside his own and perhaps book a demo. His reasoning was straightforward: a conversation can begin with something amusing before it becomes a product conversation.
This is consistent with the playfulness of GetShiftDone, although the audience and purpose have changed. Bekirov uses situations he actually encounters. A memorable detail gives someone a reason to pause; the company is close enough for the curious person to find.
He also argued that ads make more sense once an early company has worked out its product and wants to scale. His preferred starting point was improving the product. The Wi-Fi story suggests that, meanwhile, ordinary life can supply a modest marketing department of its own.
A company he wants to keep running
Bekirov's writing makes room for interests that do not fit neatly in a founder biography. He has described earning an A2 motorcycle license, taking around 20 scuba dives and skipping lectures to travel to a hackathon abroad. He likes trying things, and dislikes planning every part of life in advance. The argument is personal rather than universal: he wants principles he can carry between situations.
His essays also show a founder who takes help seriously. He has thanked the people who brought him into startups and mentored him, and described making room for early supporters to invest. His hopes include building a company he enjoys running, owning cars and motorcycles, finding a partner and having a place to call home.
That final wish gives the opening scene a different weight. The three coding sessions, the move away from university and the company are parts of a life still being arranged. He has work to do, and a fairly concrete idea of why he wants the chance to do it.
Sparkles carries one version of that wish into an office: let the person with an idea get close enough to try it. There will still be setup, review and decisions to make. Bekirov is trying to shorten the wait before the first useful change.