Independent technology practice

I design and deliver the systems your business actually runs on.

Unclear expectations in, a working digital service out. I sit with the business, then I build.

Work inside three large US asset managers. Before that, bespoke systems for healthcare, banking, transportation, and engineering.

Start a conversation

The shift

Coding got cheap. Judgment did not.

Anyone can produce software now. That is not the scarce part. The scarce part is deciding what should exist, at what cost and risk, and then making it exist in a company that already has a business to run.

I have sat on both sides of that table: with operators who know what they need in plain language, and with teams who can only speak in tickets. I translate. Then I ship.

I use AI to build faster than a traditional team. I do not use it as an excuse to skip architecture, security, or the question of whether the thing should exist at all.

How I work

Sit with the business. Decide. Build. Hand it over.

  1. 01

    Sit with the business

    I start with the commercial intent, the constraints, and the people who will live with the result. Vague is fine. That is usually where the real requirement is hiding.

  2. 02

    Decide

    What to build, what to buy, what to stop. Architecture and risk in language a non-engineer can accept or reject. The expensive mistake is building the wrong service well.

  3. 03

    Build

    I design and deliver the system, including AI-assisted implementation when it makes the work faster without making it sloppy. You get a working service, not a slide deck.

  4. 04

    Hand it over

    Documentation, operability, and a business that can run the thing without me in the room every week. I stay when a retainer still earns its keep. I leave when it does not.

Selected work

Outcomes, not a stack list.

Healthcare

Practice software that also satisfied the National Health Fund

A general physician practice needed its own management system. Day to day that meant appointments, medical history, and a patient registry. A lot of history still arrived on paper and had to be scanned in.

Nothing off the shelf existed for this at the time. Several doctors and nurses had to use the same system, with access control. Medical data had to be encrypted at rest. National Health Fund reporting meant complex statistics that were hard to produce by hand.

Designed and built a multi-user Windows client with a custom backend and database. It covered booking, rescheduling, and cancelling appointments; medical history notes, including paper scans and OCR; a managed patient registry; access control for doctors and nurses; encryption at rest; and the National Health Fund reporting.

One system covered the practice's automation: appointments, records, the patient registry, and fund reporting. Complex statistics for the National Health Fund were no longer troublesome to produce. Paper history could be stored and searched instead of sitting in a file.

Banking

Treasury trading at a fraction of the monopoly-platform cost

Treasury departments in banking communities needed to communicate and trade foreign exchange, fixed income, and money markets. The communities were national, industry-wide, and international.

Messages had to stay in time order. The architecture had to be distributed. Communication and trading had to be secure and auditable for treasury desks. Large monopoly platforms offered the function, but at a high price and with poor fit for each bank's own back office.

Key part of the design, architecture, and development of an international FX, fixed income, and money-markets system for banking communities, national, industry-wide, and international. The platform kept message order in time, ran as a distributed system, and gave treasury departments secure, auditable communication and trading. Integrated it with back-office systems so trading tickets could be automated, including bespoke back offices.

Banks got similar value to the large monopolized platforms at a fraction of the cost, plus straightforward integration with the back-office systems they already ran.

Transportation

Brokerage software for loads that don't fit the standard

A startup wanted to specialise in brokerage for oversized, non-standard, and ADR (dangerous goods) loads. They needed software that matched their own operational workflow, not a generic freight package.

Non-standard transport is hard to price quickly. Client, carrier, and driver all had to see load position, status, and timetable changes. Profitability of the brokerage had to be visible. Load details often arrived as free text and had to become strongly typed attributes. There was no AI to do that conversion at the time.

Designed and built the system. A calculation engine priced non-standard transport. The platform messaged both the client and the transportation entity about current load position and status. Drivers had thin clients on their phones for status reporting and timetable changes. The system tracked brokerage profitability and turned free-text descriptions into strongly typed attributes without AI.

They could process client requests efficiently and price non-standard loads quickly. Clients and carriers stayed informed on position and status. Drivers reported from the phone. The brokerage could see whether a job was worth taking, with structured data behind the messy descriptions.

Experience

Trusted in the room, then on the hook to deliver.

Recent years

Three large US asset managers

Developer, architect, product owner, technical director, systems architect, technical security advisor. Permanent roles in organisations where the cost of a bad system is not theoretical.

Earlier

Independent, bespoke systems

Healthcare, banking, transportation, and engineering operators. Software that had to match an existing business, not a pitch deck.

Foundation

Software engineering

Trained as a software engineer. The later titles were added to that skill. They did not replace it.

Fit

Who this is for.

For

  • Operators with a real business: CEO, partner, COO, or the head of a unit that needs a technical counterpart.
  • Teams that can write software but cannot turn a vague commercial ask into a service that runs.
  • A company that needs judgment and delivery from one person, not a bench of juniors behind a senior sales deck.

Not for

  • A cheap app, an MVP lottery ticket, or an AI wrapper looking for a buyer.
  • Architecture that never has to ship.
  • Staffing extra coding hours with no ownership of the outcome.

Principal

Jarosław Danilczuk

People who have worked with me tend to keep me in the conversation when the business and the technology have to meet. That is the job I want.

I spent years inside three large US asset managers, in roles that ranged from building the thing to advising on whether it should exist and whether it was safe. Before that I was independent, making systems for businesses that could not buy their way out of a unique process.

I am going independent again. AI made the building part faster, which I like. It did not replace the part where someone has to look a business in the eye and say what will actually work.

Engagement

Three ways in. We pick in conversation.

Retainer

Fractional technical leadership. I stay in the decisions: what to build, what to stop, how to hire, how to talk to vendors.

Scoped build

A specific digital service, designed and delivered. Clear edges, a working result, a handover the business can live with.

Second opinion

A system or a vendor already in flight. I will say whether it holds, what it costs to fix, and whether you should keep going.

Contact

Start a conversation.

Write a few sentences about the situation. I reply within two business days.

Write an email