Can you publish a library we already use internally?

Yes, and it is a common starting point. We take the working code, separate the reusable core from the parts that are specific to your product, design a public API around it, then add types, tests, a changelog, and a README that a stranger can follow. You decide whether it goes to npm as a public package or stays private to your organisation.

What happens if a dependency you recommend stops being maintained?

We wrap third-party code behind an interface of your own in most cases, so replacing it later touches one file rather than the whole codebase. We also record why each package was chosen and what its exit route is. If a package goes quiet, we can vendor the small ones or move to a maintained alternative at a known cost.

Do we have to make our own code open source?

No. A private package inside your registry is often the better answer, and we treat public release as a separate decision with its own review. When a client does want to publish, we check that the licence, the documentation, and the support expectations are in place before anything goes out.

How do you handle a licence problem in a dependency we already ship?

We start with a review of what is actually installed, including transitive packages, and match each one against its licence file rather than its package metadata. Where a licence creates an obligation you cannot meet, we look for a permissively licensed alternative, or we replace the call site with our own implementation of the small part you use.

Can you integrate an existing component instead of building one?

That is often the cheaper path. We assess the project's release activity, issue handling, security history, licence, and bundle size, then integrate it behind a thin adapter with a pinned version. You get the saved development time without tying your codebase directly to someone else's API.

Open-Source Component Development

We package internal features as documented, versioned libraries, and we review open-source dependencies before they enter your product.

See our work:

React Support Ukraine Banner→CUSTOM BOX→

The cost of building the same thing twice

A pricing rule gets written into the customer portal. Months later someone writes the same rule for the admin dashboard, with a different rounding step at the end. A year on the mobile view carries a third copy, and support tickets about wrong totals cannot be traced to one source. Duplicated logic is cheap to create and expensive to keep, because every fix has to be applied in each place it lives.

The other failure runs the opposite way. A package gets added to hit a deadline and is never reviewed again. Two years later it has one contributor, no recent release, an unread security advisory, and a licence your procurement team wants to discuss. That dependency was free in the way an unpaid invoice is free.

Both situations come from a decision that was skipped: which logic you own as a versioned package, and which you borrow from a project that has shown it can be maintained. This page covers the work on both sides of that line.

How we decide between adopting and writing

We run the same short review before writing a line of code, and in reverse when a client asks us to publish something of their own.

Who maintains the package, and how often do they ship? We look at the release history, the time between an issue being opened and answered, and whether maintainers merge outside contributions. One person with no recent activity is a real risk that happens to cost nothing today.

What does the licence actually permit for your use? MIT and Apache 2.0 are usually straightforward. GPL and AGPL carry obligations that matter when you redistribute the software or offer it as a hosted service, and commercial licences sometimes change terms by revenue band. We read the licence files, including those of transitive dependencies, rather than trusting a field in the package manifest.

How large is the dependency tree? A small convenience package can pull in dozens of transitive modules, and every one of them is code running inside your product that nobody on your team reviewed. Where a lighter option or a small amount of our own code achieves the same thing, we take that route.

Does it do more than you need? A framework adopted for one screen tends to get asked to solve five more problems later. We compare the scope of the package against the requirement in front of us, and we are willing to say that a hundred lines of our own code is the smaller commitment.

When the answers are thin, we write the piece ourselves. When they are strong, we adopt the package behind an interface we control, so a later replacement touches one file.

Who this is for

This work suits products with more than one surface: a SaaS application with a web app and an admin console, a company with a website and a mobile client, an agency that keeps rebuilding the same widget for different clients. It also fits teams that already ship open-source dependencies and need a defensible answer about licences and supply chain before a client security review or an acquisition.

What we deliver

Packaging an internal feature as a library

We start by separating the reusable core from the parts that are specific to your product. Configuration, logging, and transport stay outside the library; the logic that does the actual work goes inside. From there we design the public API around what callers need, which usually means fewer options and clearer names than the internal version had.

Semantic versioning is part of the deliverable. We document what counts as a breaking change for this specific library, keep deprecations working for at least one minor release, and write a changelog that says what changed and what a caller has to do about it. A new major version is a promise about how much work your consumers will face.

Documentation means a README a stranger can follow to a working result in a few minutes, one runnable example per main use case, and an honest list of what the library does not support. Types ship with the package where the ecosystem allows it. Releases run through CI with tests, a version bump, and a published artefact, so publishing is not a manual ritual one person remembers.

Adopting an external component

Integration work starts with the review above, then a thin adapter layer between your application and the package. Your code calls your own interface, and the package sits behind it. Pinning the version and committing the lockfile keeps a fresh install from silently changing behaviour, and automated dependency scanning goes into your existing pipeline.

We also record the exit route for each dependency we add: what happens if the project stops releasing, how much of the package your code depends on, and how long a replacement would take. Long-lived forks are the outcome we avoid. If a fork is truly needed, we keep the patch small, rebase it on upstream releases, and try to land it upstream first, because a fork you cannot rebase is a copy you maintain in full.

How the engagement runs

A short assessment phase comes first, usually a few days. We read the code or the candidate packages, produce the licence and dependency findings, and recommend build, adopt, or adopt behind a wrapper. You get that recommendation in writing before any larger commitment.

The build phase follows, and its length depends on how much of the API is already settled. Packaging a working internal feature moves faster than designing one from nothing, and an integration is usually the shortest of the three. If the library will be public, we finish with a release checklist: licence file, README, contribution notes, and a stated support expectation.

What it costs

Work is billed at our flat rate of $39 per hour, or quoted as a fixed scope once we have seen the code. A library extraction with documentation typically runs a few weeks of part-time effort, while an integration behind an adapter takes days. The smallest published order on our pricing page, the AI assistant and workflow automation engagement, sits at $1,800 to $3,900 across one to three weeks, and most component projects land at or below that size. Scope is driven by four things: how much of the code is genuinely reusable, whether the API is already proven, whether the licence review turns up anything contentious, and how much documentation your consumers need. The pricing page explains the hourly and monthly capacity models.

Proof

React Support Ukraine Banner is an open-source React component we published to npm under the MIT licence. It renders a support banner for UNITED24, ships written in TypeScript, and needed no separate CSS import from version 1.1.0 onward. It proves we can take a small idea through API design, versioning, documentation, and a public release that other teams install without talking to us.

Custom Box is a native iOS application we built for BandC IND., a Manhattan box manufacturer, so their sales team could price custom-sized boxes on the spot. The pricing logic lived in one place inside the app and had to work with the company's existing systems, and training followed the launch. It proves we treat calculation logic as a component with a defined interface, and that we stay through integration and handover rather than stopping at delivery.

Related services

Web development for the front-end and back-end work around the components we build
Custom plugin and extension development when the reusable piece has to extend a platform you already run
API development and integration for the interfaces a shared library or adopted dependency talks to
Security audit and malware removal when a dependency review has to become a full site investigation
Vibe-coded app rescue for codebases assembled quickly from many small packages that need sorting out

Next step

Send us the feature you keep rebuilding, or the package you are unsure about adopting. We will say which of the two this should be, and what it would take.

Contact us with a repository link or a short description, or run the requirement through the Vasilkoff.info estimator to get an initial scope and cost range before you speak to anyone.