u/gembaeood

Title: Seeking Pre-Seed Angel Investor | AI-Native Operating System for High-Risk Industrial Work (Industrial SaaS)

Stage: Pre-seed (MVP in development)

Industry: Industrial SaaS / AI / Safety Tech

Location: Bulgaria (EU)

Funding Goal: €300 000

Use of Funds:

• Complete the initial product ("wedge")
• External audits & Marketing
• Run pilot deployments with industrial contractors
• Expand engineering and go-to-market
• Customer acquisition

Traction:

• Founder with 20 years of experience in IT and the petrochemical industry.
• Building Permitiv, an AI-native operating system for high-risk industrial operations.
• Multi-tenant platform architecture completed, with Workforce & Certifications and Digital Permit modules already running in the development environment.
• Parent company has generated approximately €60k in industrial services revenue during H1 2026 and already operates in the target market, providing direct customer access for pilots.

The Problem

Heavy industry still relies on paper permits, Excel spreadsheets, radios, WhatsApp, and manual workflows to manage safety-critical operations. This creates delays, compliance risks, unnecessary costs, and avoidable safety incidents.

The Solution

Permitiv replaces fragmented tools with a single AI-native platform for industrial contractors and plant operators. The platform combines AI-assisted administration with deterministic, rule-based safety workflows, ensuring AI handles paperwork while humans retain control over every safety-critical decision.

The first commercial modules focus on:

• Digital Permit to Work
• Workforce & certification management
• AI-powered bidding and estimation
• Live safety monitoring
• Project and crew planning

The platform is designed as a two-sided network connecting industrial plants and contractors, creating strong network effects as each new customer brings additional organizations onto the platform.

What I'm Looking For

I'm seeking an angel investor with experience in B2B SaaS, industrial technology, AI, or enterprise software who can contribute both capital and strategic guidance during the pre-seed stage.

Happy to share the investor brief, product roadmap, and technical architecture with interested investors.

Hi,

My name is Slavcho, and I'm the founder and lead developer of Permitiv.

I'm also the founder of a technology studio based in Bulgaria (EU). Over the years, my team and I have built Linux server infrastructure, backend systems, AI integrations, payment platforms, and blockchain solutions. Alongside that, we also operate in heavy industry, organizing skilled crews for refinery shutdowns and industrial turnarounds.

That combination led us to a problem we've experienced firsthand.

Despite being some of the world's most safety-critical workplaces, refineries, petrochemical plants, and industrial contractors still manage permits, workforce certifications, planning, equipment, and compliance using paper forms, Excel spreadsheets, phone calls, radios, and WhatsApp. Administrative work that should take minutes often takes days, creating unnecessary costs, delays, and safety risks.

That's why we're building Permitiv.

Permitiv is an AI-native operating system for high-risk industrial work. It combines digital Permit-to-Work, workforce and certification management, AI-powered bidding and estimation, live safety monitoring, project planning, equipment management, and compliance into one platform.

Our philosophy is simple:

AI does the paperwork. Humans sign the safety.

Every safety-critical decision remains deterministic, auditable, and approved by qualified personnel, while AI eliminates the administrative burden around it.

We're at the very beginning of the journey. Over the past months, we've spent most of our time validating workflows, speaking with people in the industry, and turning years of real operational experience into a complete product architecture. We only recently started implementing the core platform and are now focused on turning that blueprint into production software.

We deliberately chose to spend more time designing the right product than rushing to build features before fully understanding the problem.

We're still very early and would genuinely appreciate feedback from founders, operators, and investors who know industrial software or vertical SaaS.

If this resonates with you, I'd love to hear your thoughts, answer questions, or show you what we're building.

https://permitiv.com/investors/

Thanks for reading!

Slavcho

Founder & Lead Developer, Permitiv

Hello,

I'm currently working on an EVM event listener for a crypto payment gateway, and I'm facing a dilemma regarding the best way to handle chain reorganizations. Specifically, I'm trying to figure out the right approach for dealing with the risk that a reorg could remove transactions from a reorganized block, including legitimate payments.

What are the current best practices for handling this in production systems?

I'd also like to share my current thinking and hear whether I'm on the right track or missing something.

My idea is to make the number of required confirmations depend on the payment amount. For example:

• Payments up to $100: confirm immediately (0 confirmations).
• Payments between $100 and $1,000: wait for a small number of confirmations (roughly equivalent to about 1 minute).
• Payments between $1,000 and $10,000: wait about 3 minutes worth of confirmations.
• Payments above $10,000: wait at least 5 minutes worth of confirmations.

I'm expressing these thresholds in minutes only for simplicity. In practice, the implementation would use block confirmations, since every blockchain has different block times.

With this approach, I assume I would need multiple webhook states, something like:

• Payment Pending
• Payment Received – Awaiting Confirmations
• Payment Confirmed

That way, merchants can distinguish between a payment that has been detected on-chain and one that has reached the required confirmation threshold.

To be honest, I couldn't come up with a more balanced approach than this. I'd really appreciate any advice, suggestions, or insight from developers who have already dealt with this problem.

Thank you!

As of May 2026, PSD3 is officially a fact in Europe. Together with MiCA (January 2026), a heavy regulatory environment is taking shape, under which all fintech startups must adapt.

The good news for merchants:

They can now officially accept invoices and payments with stablecoins like USDC, USDT, and EURC. No additional licenses are required on their side.

The bad news for fintech SaaS companies (such as gateways):

If your software platform executes a payment order on behalf of a client to a merchant – you are subject to PSD3 licensing. Even if you do not hold funds (non-custodial).

The key question for startups:

Where is the line between:

· "technical service provider" (outside scope)

· and "payment service provider" (requires a license)

This is precisely the subtle point that will determine whether a project survives or perishes under regulations.

Every project is different. The architectural decision of whether to be custodial or non-custodial, whether to execute orders on behalf of the client or only provide a technical interface – this makes the difference between "licensed" and "unlicensed".

What do you think? Is anyone here working on a fintech/crypto project in the EU? How are MiCA + PSD3 affecting you?

Regards

hello, I am a node.js programmer and devops with 15+ years of experience, as well as 3+ years of experience in evm, fintech and solidity development. I have an affinity for crypto and crypto trading. over the years I have used dozens of different trading bots. in the meme token boom, many of the random bots I use lead me to losses and that annoys me extremely 😞 not that the bots are bad, but the fact that hackers are very inventive leads me to constant losses in most cases. how is it with your meme sniper bots, please share.

due to the fact that bots constantly get hacked, I started building my own sniper for evm and more specifically for uniswap v3 and v4 LP. the main idea is for the sniper to be able to check whether the code is malicious or not. the real problem I am facing is the relatively new liquidity standard of uniswap v4 and its hooks. in v2 and v3 hooks didn't exist and everything was in the contract code, but now the contract may look like a typical erc20 token and the scam may be hidden in the hook. something I am struggling with muech more because the contract code is clean but actually it's not!

I want to hear your opinion what sniper bots you use, is there anyone among you who is building such a thing for ethereum and base (mine is for those) and what losses do you suffer.

I personally have losses of around 75% from using random bots and now with the custom one I am building, losses have dropped to 25% thanks to the many checks I integrate before the bot buys. - yes, I lose the first blocks that way, but despite that it's better to play a verified token than every token 😃

Cheers 😄