I build products, developer tools and infrastructure — from messy real-world problems to production systems.

NIPE Solutions  ·  NIPE Open Source  ·  Unravio  ·  Austria 🇦🇹

I like building software where product, architecture, data and infrastructure meet.

I started programming in 2011 with Java, initially building Minecraft plugins, mini-games and eventually game-server networks serving more than 400 concurrent players.

That curiosity about how systems work turned into a career spanning enterprise software, finance, e-commerce, distributed systems, infrastructure and product development.

Today, I'm a Senior Full-Stack Engineer and founder of NIPE Solutions.

I tend to work across the entire lifecycle:

idea
→ domain model
→ architecture
→ implementation
→ infrastructure
→ deployment
→ observability
→ production
→ iteration

I'm particularly interested in problems involving large datasets, asynchronous workflows, browser behavior, distributed systems and real-world edge cases.

Unravio is a data and intelligence platform for turning fragmented marketplace information into structured, useful and actionable data.

The interesting part isn't only the product interface. The underlying system involves:

• large-scale data ingestion;
• marketplace crawling and discovery;
• normalization and canonical schemas;
• enrichment and classification;
• product and price intelligence;
• asynchronous processing;
• cross-market entity matching;
• APIs and data products;
• browser-integrated workflows;
• observability and distributed infrastructure.

It is exactly the type of engineering problem I enjoy:

messy real-world data → structured systems → useful products

I'm building a growing collection of focused primitives and tools for the web.

The philosophy is deliberately simple:

Solve small, difficult problems well enough that other developers should not need to solve them again.

Projects stay independently installable and own their APIs, documentation and release cycles.

React Spring Bottom Sheet Accessible React bottom sheets with snap points, gesture/scroll coordination, focus management and interruption-safe motion.

React Swipe Actions Composable swipe-reveal actions for React rows with measured action regions, RTL semantics, keyboard interaction and optional full swipe.

React Anchored Layer Floating React content that stays attached to its anchor through portals, scrolling, resizing and layout changes — without owning popup semantics.

React Pull to Refresh Pull-to-refresh mechanics with explicit scroll ownership, resistance, thresholds and an application-owned async lifecycle.

React Drag Dismiss Drag-to-dismiss mechanics for arbitrary React content with intent detection, velocity, resistance and settling.

Caret Geometry Reliable viewport coordinates for carets in inputs, textareas and editable DOM, including observation and virtual references for floating UI.

React Viewport Reactive visual-viewport, zoom, keyboard-occlusion and safe-area geometry for React application logic when CSS or a one-off browser API read is not enough.

Readonly View Deeply readonly, lazy, live views over owner-controlled mutable JavaScript data.

Angular Flex-Layout Codemod Review-first migration tooling for removing deprecated Angular Flex Layout with compiler-aware analysis, explicit targets and diagnostics for cases that should remain manual.

I'm also experimenting with Civic Pulse, a self-hosted civic information layer with Traiskirchen, Austria as its first real-world installation.

The idea is not to build another municipal app.

It is to turn fragmented public information such as:

events
road works
warnings
waste schedules
local businesses
public facilities
mobility
open government data

into structured, source-backed information with time, place and provenance.

The broader goal is a reusable open-source platform for municipalities rather than a Traiskirchen-specific one-off.

I rarely enjoy building a feature without understanding the system around it.

A few principles I tend to come back to:

• Solve the underlying problem, not only the immediate ticket.
• Prefer explicit domain models over accidental conventions.
• Treat schemas and interfaces as product decisions.
• Keep complexity deliberate.
• Automate repetitive work.
• Make failure modes visible.
• Design observability with the system, not after it.
• Prefer evidence over assumptions — especially around browser behavior.
• Keep ownership boundaries clear.
• Don't turn a focused primitive into a framework without a very good reason.

I like moving between architecture and implementation.

One moment might involve designing a distributed ingestion pipeline; the next might involve tracking down why Safari cancels a pointer gesture or why a proxy invariant breaks for a particular built-in object.

Both are engineering.

Distributed Systems       Browser Primitives        Data Platforms
Developer Tooling         Event-Driven Systems      Software Architecture
Open Source               Geospatial Systems        Marketplace Intelligence
Infrastructure            Automation                APIs & Data Products
Schema Design             Observability             Applied AI

The projects I find most interesting usually have at least one of these properties:

The data is messy.
The browser behaves differently than expected.
The workflow is unnecessarily painful.
The system needs to survive failure.
The abstraction doesn't quite exist yet.
The obvious implementation is subtly wrong.

Those are usually good signs that there is something worth building.

I'm always interested in difficult technical problems, ambitious products, open-source collaboration and systems where engineering quality actually matters.

If you're building something interesting — or think I can help — feel free to reach out.

📫 nicholas.petrasek@nipesolutions.com

_{Build systems that make the next problem easier to solve.}