QManufacture is a small software studio run by one human and one AI. We take work held together by spreadsheets, email, copy-paste and memory, then turn the useful part into a focused tool. No “digital transformation”. No platform unless there is an actual reason to build one.
If something in your company still depends on email, spreadsheets, copy-paste or one person remembering the next step, that is a perfectly good place to start.
We map what really happens, remove pointless steps and automate the boring parts. The result can be as small as a clean internal workflow or as useful as a tool your team opens every day.
A portal, registry, booking flow, validation tool, small SaaS or something stranger. We prefer a narrow product that works over a big specification that ages in a folder.
We can connect AI to websites and internal systems through controlled MCP tools: limited permissions, explicit approvals, audit trails and rollback instead of handing an agent the keys to the building.
Start with a small paid pilot around one problem. Build the smallest version that proves the idea. Then keep it, expand it or stop. We would rather quote a narrow piece of useful work than sell a six-month “transformation programme”.
Not every messy process needs an application. We also build n8n workflows, API integrations, scheduled checks, approval flows and AI-assisted operations. If a reliable automation removes the problem, that is usually better than inventing another platform.
These are tools we are already building for recurring problems we know well. Each one can stand on its own. They share infrastructure only where that actually saves work.
Keeps document versions, approvals and proof of who accepted what. Built for the moment when “I’m pretty sure they agreed” stops being good enough.
A structured way to run tests, calculate results and keep the validation history. Mainly because spreadsheets become creative once enough people edit them.
Booking for services and consultations without forcing the whole process into somebody else’s generic calendar assumptions.
One account and one place for organizations, roles and product access, so every new tool does not need to invent login again.
QManufacture is Patryk and ChatGPT working together. That is not a cute AI feature added to the website. It is how most of the work actually gets done.
Patryk brings the problem, domain context, judgement, testing and responsibility for the real-world result. ChatGPT helps with research, challenging assumptions, product design, code, reviews, documentation and operating connected tools.
Context, priorities, product decisions, domain judgement, testing and accountability.
Analysis, design, coding, review, documentation and tool-assisted execution at a rather unreasonable pace.
Sometimes we build our own tooling because the available options are too broad, too permissive or simply solve a different problem. If the result is useful beyond QManufacture, we would rather publish it.
A safety-first MCP layer for building and managing ordinary websites and applications without WordPress. Bounded abilities, workspaces, preview/apply, SHA-256 fingerprints, backup, rollback and controlled deployments instead of remote “do whatever you want on the server”.
A generic MCP gateway for remote WordPress administration: content, site configuration, themes, extensions and maintenance operations. Designed around allowlists, preview → apply, explicit mutation confirmation, backups and reversible changes.
Accounts, organizations and audit basics can be shared. The actual rules of each product stay inside that product. It is less glamorous than an “ecosystem”, and much easier to maintain.
User, organization, membership, coarse roles and product entitlements.
Each product keeps its own logic, domain data and fine-grained authorization.
Identity, time, version and event correlation create a trail that can later be reconstructed.
Show us the spreadsheet, inbox, copied data, manual check or recurring task that keeps wasting time.
We strip out the unnecessary steps, build the smallest useful version and put it in front of the people who actually do the work.
Only after it proves useful do we add integrations, permissions, billing or the other machinery the problem genuinely needs.
Email, spreadsheets, repeated copying and manual status checks are usually a good sign that a small tool can help.
If you need to know who did what, when and against which version, we design that into the workflow instead of adding it later.
If a recurring problem deserves its own application, we can build it as a focused product rather than a feature pile.
Not a transformation workshop. Pick one process that costs time, creates mistakes or makes people swear at a spreadsheet. We can map it, decide whether software is actually justified and build a narrow first version if it is.