Peter Liszka

Founder & AI / Full-Stack Engineer

I’m Peter. I run CONVRO and work on software where the difficult part goes beyond the interface: keeping encrypted messages consistent, giving an AI assistant controlled access to a business, and making the whole thing understandable to the person using it.

CONVRO LTD

Selected engineering work

I write about the parts that need careful reasoning: what a system knows, which state survives a failure, and where an operation is allowed to happen.

The application has to decide what the model is allowed to do.

In Reesponder, I’m interested in the boundary between a useful conversation and a real change to somebody’s business. A generated API call is only a proposal. The application still has to check the customer, the scope, the configuration revision and the confirmation when it executes.

The study follows those checks through the TypeScript application, then looks at source-bound answers and the durable state behind human handoff. I explain the trade-offs and distinguish inspected tests from checks I actually ran.

The original 1 minute 18 second product film from Reesponder’s homepage. It introduces the product before the engineering details below.

Read the AI systems study Visit Reesponder

Encryption changes how I think about delivery, storage and failure.

A relay can accept a message just before the connection disappears. The browser sees a timeout, but that does not mean the send failed. With a changing encryption session, retrying is a state-management problem as much as a networking problem.

The study connects the Rust backend and shared Rust/WebAssembly protocol to the browser’s IndexedDB state. I go into Olm sessions, device identity, atomic persistence, duplicate detection and the limits of encrypted local history.

Two browser windows show Meet at 10? while the relay carries ciphertext. Hand-drawn by Peter Liszka. — Message content is encrypted between the browsers. The relay still sees routing, timing and payload-size metadata.

Readable message in the sending browser — Message content is encrypted between the browsers. The relay still sees routing, timing and payload-size metadata.

Read the Rust & encryption study Visit Cheapwork

Turning a creative brief into an explicit scope.

I want the website to make the work understandable before anybody agrees to it. The number of videos, their formats and the management around a campaign need to be visible choices, with production, recurring work and media spend kept distinct.

The implementation uses a static Next.js site with a client-side calculator. The interesting boundary is between an estimate someone can explore in a browser and a scope that can be trusted as an actual order.

Adfyo’s original 45-second brand film. The case study below concerns the website and scope calculator, rather than claiming authorship of the film. Read the film transcript.

Read the product engineering study Visit Adfyo

About me

I’m Peter, the founder of CONVRO. I work across AI support, encrypted messaging and the websites around those products. The parts I find most interesting usually sit between components.

In Cheapwork, that means asking what happens when the browser advances an encryption session but the network disappears before a send is confirmed. In Reesponder, it means separating an answer that sounds convincing from an action the application is actually allowed to perform. Those details are why I want to work on software, rather than just put an interface in front of it.

I use TypeScript, JavaScript and Python, and these projects also involve Rust, WebAssembly and relational databases. I’ve written the studies around the source and the decisions it exposes: where state lives, which operation can fail, and what the next request should do about it.

I want another engineer to be able to challenge the reasoning. I’ve kept the constraints and the tests alongside the implementation details, including where I haven’t rerun a browser test or don’t have a measured result.

Founder · CONVRO LTD

I founded CONVRO, the company behind Reesponder, Cheapwork and Adfyo. The case studies explain the software behind those products and the constraints I consider when deciding what they should do next.

Technologies I work with

Languages

TypeScript
JavaScript
Python
Rust

Web applications

React
Next.js
Fastify
WebAssembly

Data & deployment

PostgreSQL
Redis
SQLite
Docker
Nginx

Testing & further study

Vitest
Rust tests
C++
Lua

C++ and Lua are additional interests.

How I make engineering decisions

I start with the failure case.

A timeout tells me that I didn’t receive a response. It doesn’t tell me whether the other system committed the write. I look for that distinction early, because it determines the state model, the retry behavior and what the interface can honestly tell someone.

I want the boundary to be explicit.

An LLM can propose an API call; the server still has to authorize it. A browser can display a price; that doesn’t make its state a trusted invoice. I prefer to put those rules where they can be checked, rather than relying on the interface to behave.

I keep the operating cost in view.

For a public website with an interactive calculator, a static Next.js build can be enough. For messaging, SQLite is useful precisely because it is operationally small, provided I account for the single-writer constraint. I want a reason for each additional service.

I explain what I know and what I haven’t verified.

I’m comfortable discussing implementation in English with product and engineering teams. I want a review to show the proposed behavior, the trade-off and the evidence. If a result is unknown, I’d rather name it than hide it behind a confident status message.

Work with me

I’m interested in remote engineering work on AI applications, backend systems and full-stack products. Tell me what you’re building, where it gets difficult, and what you need someone to own.

team@convro.eu