WORK

Architecture changes
what becomes possible.

I design complete architectures: the functions, constraints, dependencies and decision paths that determine what a system can achieve. My work reaches from markets and enterprises to products, industrial systems and infrastructure.

I do not design isolated improvements. I design the whole system that makes the objective achievable.

BusinessMarketProductOperationsTechnologyIndustryInfrastructure
SELECTED ARCHITECTURES

Architecture determines what becomes possible.

Six different systems. Six different sets of constraints. In every case I designed the functions, dependencies and decisions that made a specific result achievable — often with resources far below what the scale would suggest.

01 / 06 MARKET / ENTERPRISE / PLATFORM ARCHITECTURE

Ja-Pojade.pl

A market-scale enterprise designed as one interdependent architecture — with resources that should have made its reach exceptionally difficult.

I designed the entire operating logic: a two-sided labour market, a web application, qualification and assignment rules, professional recruitment, insurance, commercial routes, market adoption and institutional partnerships. Each function had a purpose; each dependency had a place. The architecture, not the size of the organisation, generated the leverage.

~6,000drivers
~1,000company-side users & commissioning entities
10 + 1peak team size including me

One deliberately designed architecture connected thousands of drivers with company-side demand while extending into professional recruitment, risk protection and institutional cooperation.

Platform architectureMarket structureFunctional system designCommercial system
02 / 06 INDUSTRIAL DELIVERY SYSTEM ARCHITECTURE

Power Plant — AKPiA/HVAC System Architecture

An industrial execution architecture designed in the middle of a project whose resources, access conditions and dependencies changed continuously.

For the AKPiA/HVAC scope spanning 21 of 23 buildings, I reconstructed actual field conditions and designed the execution system around them: crew capability, task decomposition, material routes, permits, inspection, verification, commissioning interfaces and work sequencing. These were not administrative details. They were connected functions required to make the technical scope executable.

21 / 23buildings within the installation scope
>100 kmpower & control cabling
63control-and-power cabinets
~1,500field automation elements

I transformed the dependencies of a changing industrial environment into controlled, achievable technical states. That was the decisive architectural work.

AKPiA / HVACExecution structureDependency architectureCommissioning
03 / 06 PASSENGER MOBILITY

Passenger Mobility &
Premium Intercity Transport

I designed transport as an integrated experience and operating model, not as a fleet of vehicles.

Different vehicle classes had deliberately different functions, supported by driver allocation, service standards, customer experience and operational economics. Even small details — connectivity, refreshments and passenger comfort — belonged to the service architecture.

For a proposed premium Szczecin–Warsaw coach connection, I designed the complete route system: vehicle specification, reduced seating, two-city driver bases, fixed circulation, onboard service and fare economics. The target model was designed for viability at approximately 30% occupancy.

FLEET→DRIVER ALLOCATION→SERVICE STANDARD→PASSENGER EXPERIENCE→ROUTE ECONOMICS

Capacity, passenger experience and route economics were designed together before the investment decision on assets or launch.

04 / 06 LIVE BUSINESS TURNAROUND

Pandemonium

The venue could generate demand. Its operating architecture was destroying the value that demand created.

With more than PLN 100,000 in overdue obligations and closure approaching, I treated the venue as a complete control system: event programming, cash, stock, procurement, suppliers and daily responsibility.

Without a full POS system, I designed practical stock and cash controls, including manual measurement, purchasing discipline and daily verification. The existing event rhythm remained an essential revenue function rather than being cut indiscriminately.

Within approximately 90 days, the overdue balance was cleared and the venue continued operating.

EVENT RHYTHM+TRAFFIC+BAR CONTROL+CASH DISCIPLINE→RECOVERY

Recovery required two systems to operate at once: demand generation and disciplined financial control. I designed their relationship instead of sacrificing one to repair the other.

05 / 06 BUSINESS MODEL / ACQUISITION SYSTEM

Automotive Rental

Where conventional leasing excluded viable customers, I designed a different financial-product and acquisition architecture.

The market gap was not simply a rejected application. It was a mismatch between customer purchasing capacity and the acceptance logic of an existing financial product.

I connected a long-term rental model with a purchase option to positioning, website architecture, reservation, individual quotations and sales conversion.

Short vehicle-test content was designed as the opening of a defined customer path: attention, trust, a concrete monthly offer and conversion. Social media was a component of the sales architecture, not a separate publicity exercise.

CAR→SHORT TEST→ATTENTION→TRUST→MONTHLY OFFER→CONVERSION

Product logic, customer eligibility and acquisition formed one commercial architecture rather than three disconnected activities.

06 / 06 CONSUMER BUSINESS / SOCIAL CAMPAIGN

Plus-Size Fashion
+ “You Are Beautiful”

A retail architecture and an independent social campaign, each designed for its own function.

I designed the business around a customer group underserved in range, price and self-expression. The architecture connected sourcing, product selection, pricing and the store offer rather than treating those decisions separately.

Direct purchasing from China and selected Polish wholesalers supported a range that included fitted jeans, elegant clothing and expressive apparel at accessible prices.

Separately, I created the anti-fat-shaming campaign You Are Beautiful. The first packages included a bracelet carrying the message without the store logo. The message was deliberately able to exist independently of the commercial identity.

MARKET GAP→PRODUCT→SOURCING→PRICE→STORE+SOCIAL CAMPAIGN

Two architectures addressed the same customer reality: a commercial system serving her needs and a social initiative with its own independent voice.

Different systems. Different constraints. One architectural principle: design the relationships that determine the result.

SELECTED ARCHITECTURE / 01JAPOJADE.PL
MARKET / ENTERPRISE / PLATFORM ARCHITECTURE

The architecture came first.
The company was built around it.

Ja-Pojade addressed a structural failure in road transport. Companies needed qualified drivers for defined periods and assignments; experienced drivers had professional availability that traditional hiring models could not easily mobilise. I designed the missing operating layer joining those states, then built the organisation and market routes needed to bring the architecture into use.

LIVE MARKET REACH~6,000 drivers
COMPANY SIDE~1,000 users & commissioning entities
PEAK ORGANISATION10 people + me
PERSONAL FIELD LOAD~11,000 km / month
01

I designed the complete transaction — down to its dependencies.

A listing service only introduces two sides. The actual transaction requires defined competence, availability, assignment conditions, timing, compensation, contracts, verification, risk allocation and responsibility. I treated every one of these as a system function with an explicit place in the architecture.

The architecture began on large flipchart sheets. I mapped driver states and company states, the conditions for a valid match, information paths, failure conditions and the consequences of each decision. Development did not begin with screens. It began with a precise model of how the market had to behave.

That precision extended beyond the digital transaction. Recruitment, insurance, vehicle handover, industry partnerships, communications, monetisation and growth stages were designed as interdependent parts of the same system.

COMPANY DEMANDroute · period · rate · qualifications
→
MATCHING LAYERavailability · capability · assignment fit
←
DRIVER CAPACITYlicences · experience · time · availability
02

The web application implemented the logic. It did not define the enterprise.

The digital component was a proper web application: an Angular frontend, JavaScript backend, persistent user states and interaction logic between drivers and companies. It was never merely a website, nor only a mobile application.

I designed the functions and behaviours and translated them into flows, mock-ups, requirements and executable development tasks. Developers and designers implemented the interfaces and technical solutions within those architectural decisions.

As real usage exposed a new dependency, I specified the next required function and its relation to the existing system. The application evolved because the architecture was deliberately designed to accommodate that evolution.

The application never stopped being designed.

Function → dependencies → states → interfaces → implementation → observed behaviour → next architectural decision.

ANGULAR FRONTENDJAVASCRIPT BACKENDUSER STATESMARKET LOGICVERIFICATIONCOMMERCIAL FLOW
03

Market liquidity was an architectural requirement, not a marketing slogan.

This was a two-sided market. Drivers would return only if assignments were worth checking; companies would return only if the available driver pool could solve real needs. The system could not achieve usefulness by acquiring either side in isolation.

I designed adoption sequences, industry access, sales and institutional relationships to build usable density on both sides. Monetisation had to support that growth rather than consume it prematurely.

Trade fairs, media appearances, conferences, direct negotiations and professional organisations performed specific functions in the market architecture: awareness, credibility, access, feedback and adoption. Those activities were connected to the system’s growth path, not separate promotional improvisations.

SUPPLYdrivers
↔
LIQUIDITYusable density
↔
DEMANDcompanies
ADOPTION → MARKET DENSITY → PREMIUM SERVICES → STRONGER MONETISATION
04

Every market barrier became a function to design.

Some transport operators needed recruitment completed, not another interface in which to search. I designed professional recruitment as an additional system: requirements, candidate screening, competence verification and practical driving assessment by an experienced examiner and heavy-vehicle driving instructor.

Short assignments also raised risk questions that conventional annual fleet policies did not solve for an individual driver. I negotiated a dedicated daily driver-liability product with Wiener TU Vienna Insurance Group: individual cover available from a single day, at PLN 15 per day, with a PLN 50,000 coverage limit.

The insurance architecture changed who could purchase protection, for how long and under what operating conditions. It addressed a market gap that standard employer-purchased group cover had left open. Separately, SafeTrack extended the system into documented vehicle condition at handover and return.

MATCHING→QUALIFICATIONS→VERIFICATION→INSURANCE→VEHICLE CONDITION→RESPONSIBILITY
05

Extraordinary leverage was designed into the system.

At peak, the organisation comprised roughly ten people plus me. Those resources were limited relative to the functions the enterprise had to perform: architecture, product, technology, recruitment, sales, marketing, partnerships, finance coordination, institutional access and executive management.

I designed functions so they could be performed with the resources available, selected their sequence and retained architectural coherence across them. The decisive constraint was not simply how much work could be done. It was which arrangement of work could create the next required capability.

The system reached approximately 6,000 drivers and 1,000 company-side users or commissioning entities, developed paid recruitment and built relationships with major organisations and industry media. The level of reach was exceptional for the scale of the organisation behind it.

MATEUSZ
CHRZANOWSKI
ARCHITECTUREPRODUCTDEVELOPMENT MANAGEMENTOPERATIONSMARKETINGSALESPARTNERSHIPSINVESTOR RELATIONSDOCUMENTATIONEVENTS / INDUSTRY
06

The result was an enterprise-scale market architecture.

The system extended beyond its web application into recruitment operations, liability insurance, driver verification, contracts, commercial relationships, industry communication and physical institutional presence.

Cooperation with the Pomorskie Stowarzyszenie Przewoźników Drogowych included practical support and an external Ja-Pojade office. The company established visibility in the transport press and built relationships across the sector, including transport operators and institutional partners.

The architecture was the decisive work: a precise system of functions, market relationships and operational decisions that produced scale far beyond the apparent resources of the organisation.

SELECTED ARCHITECTURE / 02POWER PLANT
INDUSTRIAL DELIVERY SYSTEM ARCHITECTURE

The construction scope was defined.
The execution system had to be designed.

In this power-plant project, my responsibility covered the AKPiA/HVAC installation scope across most of the new gas-fired plant. The technical drawings defined equipment and target installations. I designed and continuously reconstructed the system that could make those requirements executable despite insufficient staff capability, missing management capacity, changing access conditions and incomplete dependencies.

FACILITY23 buildings
INSTALLATION SCOPE21 buildings
CONTRACTED SCOPE~€2.5m
FIELD ELEMENTS~1,500
01

Every number represented a dependency chain.

The scope extended across 21 of 23 buildings: approximately 11 kilometres of cable routes, over 100 kilometres of power and control cabling, around 13 kilometres of fibre protective tubes, 63 control and power cabinets and roughly 1,500 field automation elements.

A sensor mounted high in an unfinished structure was not a single task. It was an ordered system of access, equipment, safety, labour, material, installation, measurement and verification. Some installation points approached 38 metres; in difficult areas, reaching the work position could require hours.

I decomposed those dependencies before assigning the task. The architecture had to convert technically valid drawings into an executable sequence under the real conditions of the site.

~11 kmcable routes
>100 kmpower & control cabling
~13 kmfibre protective tubes
63control / power cabinets
~1,500field automation elements
~38 mmaximum installation height
02

I designed tasks around actual competence — not imaginary staffing.

Available workers had very different skill levels. I therefore built an operational capability model distinguishing physical installation, bounded technical work, electrical connections, measurements, supervision and specialist control.

I assigned work to verified competence rather than job titles. Tasks were decomposed until instructions, resources and verification could fit the people who would perform them; critical activities remained with the smaller group whose capabilities supported them.

That was not personnel administration. It was architecture: defining which human subsystem could reliably deliver which state, under what constraints and with what verification.

01PHYSICAL EXECUTIONroutes · cable laying · cabinet positioning
02DEFINED TECHNICAL TASKSbounded work under supervision
03ELECTRICAL / AUTOMATION CAPABILITYconnections · drawings · measurements
04FUNCTIONAL FOREMANcrew coordination · field explanation
05DIRECT LEAD / SPECIALIST CONTROLdiagnosis · unusual connections · commissioning
03

Missing management functions had to be absorbed into a coherent architecture.

The project lacked approximately six to eight functions in its management, technical and administrative layer, excluding the foremen ideally required in the field. Their absence did not remove the dependencies they served.

Recruitment, procurement, permits, safety, documentation, quality, measurements, workforce scheduling, reporting, interfaces with other contractors and commissioning all had to remain connected.

I designed the operating system around the resources that existed, regularly coordinating approximately eight crews and substantially more at peaks. Plans were adjusted against actual site state, not the assumption that the next contractor, delivery or access permit would be ready on schedule.

PROJECT
LEAD
TECHNICAL COORDINATIONWORKFORCEDOCUMENTATIONPROCUREMENTHSE / PERMITSMEASUREMENT / QAREPORTINGCOMMISSIONING INTERFACESFIELD SEQUENCINGADMINISTRATION
04

Verification was part of the architecture of production.

In one early task, 18 of 36 straightforward fan connections were completed incorrectly despite diagrams, photographs and conductor identification. The result showed precisely where the current task architecture exceeded the capability available to execute it.

I redesigned the work decomposition and verification paths: clearer bounded tasks, tighter technical supervision, qualification development, measurements and documented acceptance before release to the next stage.

Across more than 100 kilometres of cabling, 63 cabinets and approximately 1,500 field devices, measurement and documentation were not final paperwork. They were required transitions between states of the system.

INSTALL→MEASURE→DOCUMENT→VERIFY→RELEASE NEXT STATE
A task was not complete because somebody said it was complete.

The next function may depend on a completed task only after its condition is verified — not merely reported.

05

The site moved through states that the schedule could not control.

Construction, access, material availability and commissioning did not move in synchrony. Equipment and final software could be late; buildings could pass into controlled commissioning before our scope was complete.

I treated permits, keys, physical access and other contractors’ readiness as genuine system dependencies. When conditions changed, I redesigned the sequence instead of relying on the original plan as if it were still reality.

Where a building required ventilation before its final control software was available, I defined controlled temporary operating states and technical bypasses to preserve the necessary function without misrepresenting the completed state of the installation.

DESIGN STATEwhat should exist
≠
SITE STATEwhat physically exists
≠
COMMISSIONING STATEwhat is allowed to operate
06

The architecture made a fragmented industrial scope executable.

People, material, cabinets, routes, measurements, permits, software, controls, other contractors and commissioning were integrated into one dependency structure. Each next state had explicit prerequisites.

My engagement was to lead, coordinate and manage the AKPiA/HVAC scope. Physical installation was predominantly performed by crews; I became directly involved in unusual technical work, diagnosis, measurements and commissioning where the required competence could not responsibly be delegated.

The decisive work was architectural: repeatedly reconstructing the real situation, designing attainable next steps and maintaining the coherence of the whole despite severe constraints. The industrial installation advanced because its execution architecture connected functions that otherwise would have remained fragmented.

ACROSS DIFFERENT SYSTEMS

Different environments.
One precise architectural method.

The object can be a market, an enterprise, a digital platform, a physical product or a continental infrastructure system.

I first define what the whole system must achieve. Then I design the functions, interfaces, dependencies, constraints and decision paths that make that state reachable.

The projects above differ in scale and industry. The architectural method does not depend on the material from which a system is built.

MarketBusinessProductTechnologyIndustryInfrastructure
01 / 05
MARKET & COMMERCIAL SYSTEMS

A market is a system of conditions, not a promotional campaign.

Demand, supply, access, pricing, risk, trust, regulation and distribution are connected variables. I design the route through them as one operating structure.

An attractive product with no viable route to a customer is an incomplete architecture. So is a sales channel whose operational or financial dependencies were never defined.

MARKET MECHANISMDemand → access → channel → economics
CUSTOMER SYSTEMCustomer need → function → offer → trust

I design market mechanisms, not independent marketing activities.

02 / 05
BUSINESS & OPERATING SYSTEMS

Business performance follows the architecture of decisions.

A company is a network of responsibilities, information, resources and commercial obligations. Its performance follows the relationships between them.

I reconstruct those relationships at the actual operating level, then redesign their logic so the next required state becomes achievable.

FUNCTION→OWNER→DEPENDENCY→DECISION→CONTROL→OUTCOME

This can change business models, workforce functions, workflows, financing paths and the connection between digital and physical operations.

03 / 05
PRODUCT & PLATFORM SYSTEMS

Software implements a system. It does not replace one.

I define application states, users, functions, information paths, decision rights and constraints before deciding how they should appear in an interface.

A platform may also need verification, commercial rules, human processes, insurance, contracts and partnerships outside its software boundary.

USER STATE→FUNCTION→INFORMATION→RULE→INTERFACE→SERVICE

The architecture integrates those functions before technology is selected or developed.

04 / 05
PRODUCT-SYSTEM & TECHNOLOGY ARCHITECTURE

The product is the whole environment required for its function.

A physical device is only one constituent system. Hardware, electronics, firmware, software, security, data, services and operating procedures must perform together.

I design the dependencies between them, including the states in which conditions change, information is missing or a constituent subsystem fails.

HARDWAREFIRMWARESOFTWARE / MOBILEDATA / SECURITYSERVICE / OPERATIONSBUSINESS MODEL / MARKET

This is product-system architecture, not an isolated technology specification.

05 / 05
INDUSTRIAL & INFRASTRUCTURE SYSTEMS

Physical scale makes hidden dependencies impossible to ignore.

Industrial and infrastructure systems add site conditions, access, safety, technical interfaces, materials, teams, measurements and commissioning to the dependency structure.

TECHNICAL SYSTEMPhysical interfaces and controls designed as one coherent technical architecture
OPERATING ENVIRONMENTUtilities and operating functions structured around site constraints
INFRASTRUCTURE DELIVERYAutomation · access · field interfaces · verification · commissioning
Different material.
Same function.
ACROSS THE DECISION STACK

The architecture connects decisions that others treat separately.

Ownership, market economics, organisational functions, technology and physical constraints are not independent layers. Every architectural decision defines conditions for another. I design their interfaces so that the objective remains coherent from first principles to implementation requirements.

01OWNERSHIP / EXECUTIVE / INSTITUTIONAL
02COMMERCIAL / FINANCIAL / MARKET
03PRODUCT / ORGANISATION / OPERATIONS
04TECHNOLOGY / PROCESS / DELIVERY
05PHYSICAL EXECUTION
Different authorities and disciplines. One designed system.
SYSTEM REDESIGN & OPTIMISATION

I reconstruct the system before I design its next state.

I trace the operating system from individual actions to the dependencies governing the whole. A visible problem is a signal: the real cause may sit several organisational or technical boundaries away.

01 MAP THE REAL SYSTEM

A process map is not a map of the company.

An organisation chart tells me who reports to whom. A process map shows a selected sequence. Neither is the whole system. I rebuild the dependency graph from the work itself: who acts, what moves, where information comes from, which decision blocks the next one, what a machine is waiting for, where software is bypassed and where one local improvement quietly creates a cost somewhere else.

PEOPLEDECISIONSINFORMATIONMATERIALSOFTWAREMACHINESPHYSICAL SPACERESPONSIBILITYTIMECOST
02 FOLLOW THE DEPENDENCY

The visible failure is an entry point, not the boundary of the problem.

A delay can appear in production and begin in purchasing. A sales problem can be created by an approval path, missing information or an operating constraint much earlier in the chain. I keep following the dependency instead of stopping at the department where the symptom became visible.

That is where bottlenecks, redundant loops, duplicated work, responsibility gaps and hidden transfers of cost become obvious. The important question is not only whether each part works. It is what those parts make the whole system do.

VISIBLE SYMPTOM→DEPENDENCY CHAIN→STRUCTURAL CAUSE
03 REDESIGN THE ARCHITECTURE

Once the real system is visible, the work stops being cosmetic.

I redesign the relationships that determine the result. That can mean removing unnecessary hand-offs, changing decision rights, rebuilding information paths, moving responsibility closer to consequences, changing the relationship between digital and physical work, or replacing a workaround that has quietly become part of the operating model.

CURRENT STATEfragmented dependencies
→
REDESIGNED STATEcoherent operating architecture
04 DEFINE IMPLEMENTATION CONDITIONS

The architecture must define the conditions under which it can be implemented without losing its function.

A redesigned system is not finished when the diagram looks cleaner. It has to descend into roles, interfaces, workflows, information, software behaviour, physical constraints, measurement and acceptance. People need to know what changes, what they own and what state the next part of the system expects from them.

The result is not an optimised fragment.
It is a different operating architecture for the whole system.

MAP→ANALYSE→REDESIGN→SPECIFY
CONFIDENTIAL WORK

Professional discretion is a structural requirement.

Architectural work reveals real operating structures, decision paths, weaknesses, constraints, economic dependencies and planned changes. Such information remains inside the engagement by default.

NO UNNECESSARY SIGNAL

If information does not need to leave the system, I do not create a reason for it to leave.

Even the fact that a company is being analysed, redesigned or optimised can be useful to someone watching the market. A competitor does not need the architecture itself. A logo, a project announcement or a simple “worked with” post can be enough to start looking more closely at what changes next.

That may be all a competitive-intelligence team needs to pay closer attention to recruitment, pricing, suppliers, operations or product moves. Most of the time, nothing would happen. The point is simpler: the cost of not creating that signal is almost zero. So I do not create it.

CLIENT IDENTITYINTERNAL ARCHITECTUREOPERATIONAL WEAKNESSESINTERVENTION LOGICSENSITIVE RESULTS

I do not publish client identities or logos by default. I do not turn private work into public case studies under changed names.Confidentiality is part of the architecture engagement from the beginning.

ARCHITECTURAL PRINCIPLE

The architecture is the decisive work.

I design the functions, relationships and paths that determine what a system can become. The six selected architectures on this page show that method across very different environments and constraints.

The work begins with the objective, proceeds through the actual constraints, and ends in a complete architectural design with defined interfaces and implementation conditions. Physical execution remains a separate responsibility unless it is explicitly included in the engagement.

SELECTED ARCHITECTURESArchitectural systems across markets, enterprises and industry
CONFIDENTIAL WORKClient architecture protected by professional discretion
DESIGN RESPONSIBILITYComplete architectures, interfaces and defined conditions for execution