Tarun Vedula had a job offer he wanted and a company he was reluctant to interrupt. Taking the offer would have meant putting Zatanna on hold for a couple of years. He asked people what they thought. Most advised against staying with the company. He stayed.
The awkward detail, which he volunteered later, is that he was still working on the wrong thing. The Zatanna he chose over that offer was different from the company he runs today. His decision preserved the chance to discover a better use for the work. It bought him time, which is a less tidy prize than being proved right.
Now based in San Francisco, Vedula is Zatanna’s CEO and co-founder. He and Alex Blackwell build connections that let other software act inside existing systems. An AI agent can arrive with instructions and still be stuck outside the application where the task must happen. Zatanna works on getting it through that door.
An offer with a pause button
In his account of declining the job, Vedula remembered feeling that the company had finally reached something worth pursuing. The offer was attractive; the interruption it required was substantial. He would have to leave the project alone just as he wanted to keep testing it.
Advice did little to settle the choice. He observed that people can be more cautious when considering somebody else’s risk. The consequences would belong to him, whatever the recommendation. There is a familiar social predicament here: a room can supply opinions much faster than it can supply responsibility.
He eventually described the pleasure of working with capable, self-directed people as part of what made the choice worthwhile. Enjoyment appears in the story as a practical reason to continue. He liked doing the work. That matters when the work changes enough to invalidate the plan that first made it seem sensible.
“no job I could take would be this fun.”
Tarun Vedula
His university background places another marker on the route. Vedula’s professional profile lists the University of Wisconsin-Madison from 2022 to 2026, with activities including the Badger Herald, Delta Chi, and a jujitsu club. By 2026, Zatanna was part of Y Combinator’s Winter batch. The company lists its founding year as 2025.
The connection became the business
Zatanna’s direction emerged from the inconvenience of building its earlier application. Customers wanted it to connect to systems they already used. Vedula and Blackwell kept encountering the same integration demand. Their ability to reconstruct the underlying network requests gave them a way to respond.
The repeated question changed the significance of that work. An integration had initially been something needed to make the application useful. It could also be something another builder would need, regardless of the application that builder wanted to sell. The founders began concentrating on software access itself.
That transition makes their collaboration central to Vedula’s story. Blackwell is Zatanna’s co-founder and CTO, with a background in reverse engineering and anti-bot work. On START, the two discussed how their company came to focus on APIs. They were examining a problem that had already been consuming their own effort.
There is a useful distinction between an application’s appearance and the operations behind it. A person sees fields, menus, and buttons. Completing a task sends requests to the software’s back end. Zatanna’s approach is to reconstruct that sequence and offer it as an endpoint another program can call.
In an interview with Alexander Monahan, Vedula described mapping network requests and hosting the resulting API. He explained the ambition across websites, desktop applications, mobile applications, and software running on premises. The common thread was reaching the operation underneath the interface.
The company’s launch introduced Rithvik Vanga alongside Vedula and Blackwell. It described customers whose work depended on throughput or reliability, including logistics. The problem could recur wherever an operational system lacked a usable API. Zatanna was choosing a technical layer that crossed the boundaries of its first application.
Three hours, then a demonstration
Vedula’s product updates give the abstraction a more ordinary setting. He reported spending three hours looking for a Rocket Money API. In the demonstration that followed, he connected the mobile application to Kampala, recorded network traffic, and asked an agent to create an API for spending categories.
The sequence had a recognisable shape: search for a connection, discover an obstacle, build a way around it. The recording supplied the requests. The agent used them to construct the flow. Vedula then ran it to retrieve the information. A technical proposition became something viewers could watch happen.
It was also an example of his participation in the product’s public life. He explained what the tool was doing and invited people to try it. A founder can spend a great deal of time describing a market. Showing a specific operation gives the description something concrete to answer to.
Kampala had been an internal tool before its public release. In an early update, Vedula credited Blackwell’s work on the proxy and described the satisfaction of receiving responses from beta users. The team had already been using it to create integrations for customers.
That detail supplies a modest, personal milestone. Vedula had wondered what it took to make somebody impressed enough by a product to send back enthusiastic feedback. Receiving those messages answered the question for him. After the diagrams and infrastructure language, there was the pleasure of seeing someone else enjoy a thing the team had made.
In the public release announcement, Kampala was presented as a tool for reconstructing workflows across websites, mobile apps, and desktop apps. Users could complete a task while recording the traffic, then use the captured context to produce scripts or hosted APIs. The proposed handoff was from a demonstrated task to a repeatable operation.
On Product Hunt, Vedula introduced himself and Blackwell as the people behind the tool. He explained the proxy’s role in reverse engineering workflows, drawing on Blackwell’s experience building integrations manually. Kampala packaged part of that working method for people outside the company.
The engineer must explain the code
When Vedula announced that Zatanna was recruiting its first engineer, he offered applicants some unusually direct feedback. Slow replies had counted against candidates. So had an inability to explain anything beyond what an AI coding tool had generated.
He allowed room for people without precisely matching experience, while insisting on understanding the work. That combination is revealing. A person might arrive needing to learn reverse engineering. Arriving unable to account for the code in front of them was a different matter.
The distinction fits the company’s task. Its integrations depend on the behavior of software built by other people. A convincing piece of generated code can still encounter an expired session or an unexpected response. Somebody has to understand enough to investigate what happened.
Vedula’s expectation of quick replies also gives a glimpse of the working tempo he wants. The hiring message connected responsiveness to the company’s own pride in speed. For an applicant, that makes communication part of the job before the job has begun. The interview starts in the inbox.
A factory with people inside
Asked to describe Zatanna in two words, Vedula chose “Integration factory.” He reported that the company was regularly building web and on-premises integrations in less than a day. He also said its infrastructure processed more than a million requests an hour.
requests per hour across Zatanna’s infrastructure, in his September 2026 update.
The number turns attention toward repetition. Vedula emphasized that a later call to an endpoint should deliver the same result as the first. Creating the connection and keeping it useful are connected jobs. The factory metaphor becomes more interesting once maintenance enters the picture.
He described customers wanting a person who had built the endpoint, understood its edge cases, and could resolve problems. Even in a business designed to automate operations, he gave human ownership a prominent place. Someone remains accountable for what happens beneath the apparently simple call.
Zatanna’s present product description includes authentication, retries, session handling, and detecting changes in the systems it connects to. It describes automatic repair when tools break. These are company statements about its service, and they explain why Vedula talks about ongoing infrastructure alongside the creation of APIs.
His wider argument is that software access will become shared infrastructure. He has compared the work with other operations that companies once assembled themselves, such as payment processing and messaging. In his view, repeating the same integration labor across many businesses creates an opening for a common layer.
He has also written about software sold by the work it completes, rather than by the number of people logging in. That is his view of where the market is going. It helps explain why he cares about giving an agent a route into another system: the action is where a promised result must eventually become real.
For Vedula, the story keeps returning to work he wants to continue. He declined an offer without knowing the company’s eventual shape. He helped bring an internal tool to outside users. He now talks about the unglamorous obligations of keeping endpoints alive. The offer he left unopened gave him more time to find out which job he actually wanted.