Sued Three Times for Cold Email in Germany, He Pivoted to AI Agents, Hit Zero Churn | Daniel @ PUNKU.AI

Daniel’s starting point is a challenge to startup fundraising culture: building a SaaS company should require less money today, not more. Cloud infrastructure, startup credits, and AI-assisted development have reduced many of the costs involved in getting software off the ground.

Programs such as AWS Activate illustrate the infrastructure support available to eligible startups. Daniel also points to the ability to build software faster with AI, provided technical knowledge remains part of the process, and to distribution tools that can stretch an early-stage budget.

Yet funding expectations have moved in the opposite direction. In his experience, rounds that once supported an initial technical team and meaningful commercial progress have given way to much larger pre-seed raises.

He attributes some of this to the way the startup community defines success. Funding announcements attract attention, help companies appear credible, and support recruitment. That creates an incentive to raise more than competitors, even when the underlying business does not need the money.

Daniel would rather see founders celebrate revenue and free cash flow. His argument is not that venture capital is inherently wrong. It is that raising money should serve the company’s strategy, rather than become a substitute for one.

The Early PUNKU.AI: Selling Before Building

Daniel’s interest in entrepreneurship began during his bachelor’s degree, when he ran small projects and earned money on the side. Internships and working-student roles in German startups introduced him to SaaS and its economics.

He was drawn to the relationship between customer value and recurring revenue. A useful software product could cost a business less than the alternative, retain customers, and fund continued improvement. For Daniel, that created a compelling cycle in which both sides benefited.

One lesson from those early experiences shaped PUNKU.AI’s first offering: sell before building. The company initially operated as an AI sales development representative, or AI SDR, promising to help customers generate sales opportunities.

The offer was straightforward. PUNKU would book meetings, customers would close them, and if the service failed to produce the promised commercial results, they could get their money back.

Behind the scenes, however, there was no complete application. Daniel delivered the work himself, combining existing services, outbound infrastructure, and Python scripts to automate the most painful tasks. He describes himself as having been the back end.

This approach helped test whether customers valued the outcome before he invested in a full product. It also exposed the operational complexity of delivering that outcome. A minimal product still needed to be viable: the missing interface could be tolerated only if the service produced something customers genuinely wanted.

Why Cold Outbound Became a Dead End

Competition alone did not persuade Daniel to abandon AI SDR. Sales software had always been crowded, and he believed there was an opening in Germany and Europe. The larger problem was dependence on email infrastructure that kept changing.

His outbound process involved multiple domains, mailbox setup, warm-up periods, careful sending volumes, and personalized copy. As email providers tightened anti-spam enforcement, the rules and practical limits shifted. What worked previously became less reliable, creating a continuing cycle of infrastructure changes.

Daniel also saw diminishing returns from personalization. When highly tailored messages became easy to generate, personalization itself stopped being a strong differentiator. Recipients increasingly recognized the automated sales approach behind the message.

Legal exposure added another problem. Daniel reports being sued three times over cold email in Germany. He says he won one case and settled two, describing claims of around €3,000 and settlements of around €300.

These were his experiences rather than a complete guide to German marketing law, but they changed the business calculation. A product already facing unstable delivery conditions also exposed him to legal risk. Continuing to optimize the same model no longer looked attractive.

The decision to pivot was therefore about more than finding a less crowded category. Daniel wanted a business whose value did not depend so heavily on an acquisition channel he could not control.

A Customer Request Opened a Different Market

The opportunity came from a customer reached through an email campaign. Rather than asking for more outbound sales, the customer wanted a chatbot for their website.

After PUNKU set it up, the customer asked for a connection to the booking system used to sell and manage tickets. For a small account, this was a substantial custom request. Daniel initially saw it as the kind of work an enterprise customer might demand, but decided to build it anyway.

That decision changed the direction of the company. The chatbot could now do more than answer questions using website information. With access to ticketing, it could help turn an inquiry into a booking.

Someone asking about an attraction could receive an answer and then a practical next step: an available visit time and a link to buy tickets. PUNKU brought some of its earlier sales-oriented logic into a customer-initiated conversation, rather than using it to send unsolicited messages.

The customer recommended the product to others. Daniel describes Europe’s attraction and tourism operators as a close-knit community, where recommendations move through personal relationships and WhatsApp groups. A successful implementation became a route to similar businesses.

PUNKU’s audience changed almost entirely. Instead of primarily serving startups doing B2B outbound, it began focusing on small European entertainment and tourism businesses.

Making the Value Proposition Easy to Measure

The initial pitch for the new product was deliberately concrete: add a sales-focused chat widget to the website for around 200 per month. If it did not generate at least twice that amount in revenue after a month, the customer could get their money back.

Daniel acknowledges that this was relatively expensive for a basic chatbot. The distinction was that PUNKU was selling a commercial outcome, not simply a conversation interface.

At the time of the conversation, he reported that no customer had requested a refund and none had churned. Those results were encouraging, although they describe the business at that point rather than establish a universal retention benchmark.

The next stage of product development came from continuing to speak with customers. Once the website agent worked, operators began identifying similar problems elsewhere:

• Email: Repeated customer questions that accumulated throughout the working day.
• WhatsApp: Another channel where the same information and booking assistance were needed.
• Phone: Calls that could be answered around the clock, with ticket links sent by SMS or email.

Daniel sees the founder’s job as drawing these use cases out of the customer’s daily work. The opportunity was not to add AI features indiscriminately, but to understand where the same capabilities could create more value.

PUNKU now describes its broader product as an agent builder: customers explain the task or agent they need, and the platform builds it. Its promise also includes maintaining agents as models and software integrations change.

Zero Churn Starts with Everyday Value

Daniel does not attribute retention to having a uniquely novel chatbot. He recognizes that chatbots are a crowded category. For PUNKU, the chatbot is a manageable starting point for customers who may be unfamiliar with AI.

European operators can have concerns about privacy, regulation, and where an agent gets its answers. The European Commission’s AI Act overview provides context for that regulatory environment. Daniel’s approach is to begin with a narrow use case, explain the information behind the answers, and demonstrate practical value before expanding.

For attraction operators, that value is both financial and personal. They may spend the day serving customers and keeping a physical business running, then spend the evening answering accumulated messages. An agent that handles routine inquiries can remove work from precisely the hours they would otherwise use to recover.

Revenue generated and time saved reinforce each other. Customers see more bookings while also experiencing a lighter administrative workload. As PUNKU expands from chat into email and phone, it becomes more closely connected to how the business operates.

That is the combination Daniel considers particularly sticky: customers can see the results in their numbers and feel the difference in their day.

Monthly Contracts as a Retention Test

One of Daniel’s more deliberate choices was to start with monthly subscriptions that customers could cancel at any time. Other founders encouraged him to require annual commitments, but he wanted a clearer signal.

If customers were unhappy, he preferred to learn within the first few months. A twelve-month contract could make retention appear healthy while concealing weak value until renewal.

He also accepted hands-on integration work that resembled an agency service. At the small subscription prices involved, the immediate return on his time was not attractive. However, it helped the team understand customer workflows and build a more deeply integrated solution.

After roughly six months, the annual-contract conversation became different. PUNKU could point to revenue generated, tickets sold, and emails answered. Customers had experienced the benefit rather than merely heard a promise.

Daniel says he did not need to offer free months or annual discounts. He could simply ask whether the customer preferred a yearly invoice and bank transfer. The longer commitment followed demonstrated value instead of preceding it.

An Italian Castle Owner Put the Proposition to the Test

One customer captures the importance of a clear offer particularly well: a 63-year-old castle owner in Italy who became one of PUNKU’s most active users.

Daniel did not speak Italian. She spoke little English and did not speak German. He relied on his Spanish, a few Italian words, and repeated explanations about answering questions and selling tickets.

Much of the detailed pitch may have been lost, but the essential proposition was understood: pay €200, have an agent help answer inquiries and sell tickets, and receive the money back if dissatisfied.

She signed up and later built her own AI agent. For Daniel, the experience showed how a practical outcome could make an unfamiliar technology approachable. The customer did not need a sophisticated explanation of AI models to understand the benefit to her business.

Partnerships Built Around the Customer’s Core Software

PUNKU tested channels including cold email, LinkedIn, content, and Meta advertising. Daniel did not present any of these as a fully established marketing engine. Partnerships, however, had become a particularly effective route to customers.

The clearest example involved bookingkit, a ticketing platform used by the operators PUNKU wanted to serve. For those businesses, the booking system was central infrastructure. Whether PUNKU connected properly to it mattered more than which AI model powered the agent.

The partnership began with an existing customer requesting an integration. PUNKU delivered it, the customer was happy, and that customer communicated the result to the booking platform. The discussion could then move from a speculative partnership pitch to an implementation with demonstrated demand.

The exchange was practical: PUNKU would contribute a deep integration, customer examples, and revenue sharing; the partner would help bring the solution to its customer base. Daniel describes co-developing an MCP connection as part of this work.

His process offers several useful principles:

• Start with customer pull: A shared customer asking for the connection creates a stronger opening than an unsolicited request for distribution.
• Deliver a successful implementation: A working customer example gives both sides something concrete to evaluate.
• Define mutual obligations: PUNKU used a letter of intent to clarify responsibilities.
• Set a time boundary: Repeatedly extending an uncertain partnership can consume months without producing results.

This also changes how founders might evaluate custom work. An integration that looks uneconomic for one small account may be worthwhile if it creates access to a relevant ecosystem. The important question is whether there is a credible path from that work to repeatable distribution.

EWOR, Community, and Demonstrating Progress

Joining EWOR was another milestone for Daniel. He values the access to experienced founders, mentors, previous fellows, and peers working through similar challenges.

His application journey was not immediate. He first applied as a solo founder with limited traction while PUNKU was still an AI SDR business. He progressed through several interviews but was rejected. He did not apply in the following cycle, a decision he now questions, and was accepted on a later application.

Daniel describes EWOR as highly selective, citing a 0.1% acceptance rate. His advice is to identify what makes an applicant exceptional and connect it directly to the venture. Broad claims of ambition are less persuasive than evidence of a particular strength that creates an advantage.

He also encourages founders to apply before they feel completely ready. Revisiting an earlier application can reveal how much progress has been made—or how little. He believes repeat applications may help show trajectory, although he presents that as his interpretation rather than a confirmed selection policy.

The broader lesson is to convey momentum through evidence. Daniel warns against literally telling an investor or potential colleague, “I’m doing this with or without you.” Growth, customer results, and continued execution communicate determination more effectively than a confrontational statement.

Profitability as PUNKU’s Independence Day

Alongside joining EWOR, Daniel’s other major milestone was reaching profitability in May of the year discussed. He considered marking the occasion as PUNKU’s “Independence Day.”

The name reflects the options profitability creates. A company that covers its costs is less dependent on raising money to keep operating. It can still pursue investment, but with greater control over timing and terms.

That connects to a wider principle Daniel calls building optionality. Whether seeking investment, a job, or another opportunity, pursuing only one path creates dependence on a single outcome. Developing several credible options makes decisions easier and confidence less fragile.

For founders who spend much of their time addressing problems, these milestones also deserve recognition. Revenue growth, profitability, and strong retention are not merely inputs to the next target. They are meaningful achievements in their own right.

Moving from Solo Founder to a Co-Founder Partnership

Daniel encountered skepticism about being a solo founder, even though he raised money and hired a technical team. Eventually, an exceptional team member became a potential co-founder: someone who understood the vision, took ownership, and consistently delivered.

Rather than remain solo to prove a point, Daniel offered him a co-founder role. The company’s needs mattered more than defending the identity of being a solo founder.

He had already tried several co-founder relationships, and those experiences shaped a more explicit evaluation process.

1. Identify complementary skills. Daniel’s strengths were more commercial, so he sought technical ownership rather than a duplicate of his own capabilities.
2. Write down the role. Define the responsibilities the business actually needs, rather than relying on a broad title such as “technical co-founder.”
3. Agree on success together. Milestones and expectations should be jointly understood, not imposed without discussion.
4. Set checkpoints and a decision date. Daniel suggests reviews after a week, a month, and three months, with a clearly bounded trial.
5. Address problems directly. If the relationship is not working, avoiding the conversation only prolongs the uncertainty.

In PUNKU’s case, ownership needed to cover specific systems and customer experiences: the agent-building engine, ongoing improvements to phone and email agents, customer feedback, and front-end work.

That ownership also required real decision-making authority. Daniel may challenge a technical decision, but his co-founder Peter has the final call within his area. Without that autonomy, Daniel argues, a supposed co-founder becomes an employee with a large equity allocation.

Character and Working Habits Matter Beyond Technical Skill

Technical competence is only part of Daniel’s assessment. He places considerable weight on grit, ethics, humility, and the ability to disagree respectfully.

The difficult test is not whether someone wants to join a promising, funded company. It is whether they remain dependable when uncertainty increases or a serious setback occurs.

Daniel is skeptical of relying on hypothetical “co-founder dating” questions. Someone’s stated preference about a future exit may reveal less than their actual behavior under pressure. He prefers hearing their life story, including how they describe challenges and their own role in events.

Working alongside a potential co-founder offers another source of evidence. Daniel pays attention to punctuality, concentration, distractions, and the quality of finished work. His personal standards are demanding, but the underlying concern is compatibility: the founders need working habits they can sustain together.

He also distinguishes productive effort from performative long hours. Staying late means little if much of the day disappears into messaging, lengthy breaks, and socializing. The more useful question is whether the work itself is good.

His preferred quality check is simple: would the person be proud to publish the work with their name attached?

Moving Faster Without Letting Worry Take Over

Daniel encourages founders to act faster because action produces information. Research has a place, but it needs a time limit. A few focused days can be useful; repeatedly extending research can become a way to avoid a decision.

His more personal lesson concerns overthinking. Financial pressure, difficult relationships, and strategic questions do not disappear when a founder closes a laptop. They can crowd out the attention needed for the task at hand.

One technique he found helpful is scheduling a specific time to think about a concern. If a new market is consuming attention, for example, he can reserve an hour on Monday evening to work through it.

The purpose is not to ignore the issue. It is to give it a defined place. When it interrupts other work, he can remind himself that time has already been set aside.

Community provides a different form of support. Having other founders to speak with makes room for shared experiences, practical advice, and recognition of progress—not only a continuing discussion of what might go wrong.