Your process works. Your software doesn't.
We build custom software for mid-size companies that have outgrown spreadsheets and off-the-shelf tools. It fits your operation instead of forcing your operation to fit the tool.
Start a conversationBeyond generic software.
Fulcrum Product Works is a product, design, and technology consultancy. Generic tools are built for a generic business. The gap between that and how you actually run shows up as spreadsheets, workarounds, and knowledge that lives in one person's head.
Manual processes cost you time, money, and mistakes. We build the tools that take all three down.
We don't just advise. We design, build, and deploy the custom software, AI tooling, and platforms that run the business.
Product direction and execution.
Product, Design & Technology Leadership
You know the business. You need someone to decide what to build. Product strategy, research, design, architecture, and roadmap, with senior judgment attached, for companies that need that leadership without a full-time executive hire.
Custom Platform Engineering
The software you need doesn't exist yet. We design and build internal platforms around your actual workflows, rules, and exceptions, rather than bending the operation to fit a product built for somebody else.
Workflow Automation
Your people shouldn't have to be the integration layer. We connect systems, automate the repeatable work, and apply AI where it improves a specific decision or workflow, not as an end in itself.
Core principles.
We build things that work, and we stand behind them.
Accountability
We own the outcome, not just the deliverable. If what we build doesn't hold up, that's ours to fix.
Operational Precision
Complex workflows require exactness. We build systems that remove ambiguity and hold up under pressure, so the process doesn't depend on someone remembering the exception.
Pragmatism
Practical value over novelty. Every architectural choice has to earn its place against a real business problem.
Durable Craft
We build systems designed to last. Careful engineering and plain, functional design, so what we hand over is still working and still legible to whoever inherits it later.
Three steps, one relationship.
Most engagements open with a short paid project, usually one to two weeks. We sit with your operation, map how work actually moves from first contact to cash, and find the place it breaks.
You leave with a prioritized plan and one working improvement, whether or not we ever work together again. Anything bigger is a decision you make after you've seen the work.
When the answer is "you need software that doesn't exist yet," we design and build it. Discovery, specification, build, handoff. Scoped and priced individually as a fixed-scope proposal, so you know the number before we start.
The person who decided what to build is the person who builds it. Nothing gets passed off to a team that wasn't part of those decisions.
Ongoing technology leadership at a fixed monthly rate: roadmap and architecture decisions, vendor calls, and hands-on build time as the operation changes. Predictable for your budget, and it means we're already in the details when something urgent lands.
Most clients stay here. You could also leave. Every engagement ships complete documentation and a knowledge base, so your team can run what we built without us.
You can enter at any step. Some companies already know what they need built. Some already have the software and need someone to own it. Most start at step one.
Not sure which fits? That's what the first call is for. It's free, and you'll leave with a recommendation either way.
What the work looks like.
Pricing 66,000 parts in 3.7 seconds.
A heavy-equipment parts distributor was spending 4 to 5 hours of skilled manual work every month repricing a single vendor's catalog. One of several vendors, tens of thousands of parts each, with layered rules and exceptions that lived in one person's head.
We turned the rules into a tested pricing engine. The same monthly pass now runs in 3.7 seconds. It reproduces the manual result exactly.
Selling 4,146 products they didn't carry.
The same distributor dropped 5,577 parts from a vendor catalog between July and August. Nobody made a list of which were still for sale on the site, because the people who maintain the catalog and the people who watch the storefront are different people.
We reconciled the catalog against the live store. 4,146 were still up and still purchasable.
Nobody inside the company knew.
A marketing manager found the problem in the code.
Product, design and marketing at a publicly traded lender each kept their own version of what was true. What shipped, what changed, what the numbers said. Reconciling those versions was somebody's job every week.
We built a shared context system wired into the project management software, the analytics tooling, and the data warehouse. It posted changes as they happened and kept the documentation current without anyone maintaining it.
Two weeks after five people were onboarded, a product manager and a marketing manager had each traced a reporting problem on a consumer funnel back to its cause in the code. Neither of them writes code.
That's what Fulcrum leaves behind on every engagement. A knowledge base isn't a parting gift. It's what lets people see problems they'd otherwise miss.
This is the shape of most Fulcrum work: find the operational bottleneck, encode the judgment, keep people on the decisions that need them.
Patrick Boggs, founder.
I've spent 25 years building software. The first thirteen in design and engineering, the last twelve leading product, most of it in highly regulated industries building complex B2B2C systems where a transaction has to satisfy more than one party at once.
In national automotive marketplaces and in consumer lending, that meant enterprise platforms carrying real transaction volume for thousands of dealers and the customers buying from them, where compliance, uptime, and conversion all had to hold at once. Mission-critical in the plain sense: when it breaks, deals stop closing.
I do the customer research myself rather than reading someone else's summary of it, and I still build. When Fulcrum says "we build," it starts with me, which is why the person who decides what to build here is the same person who builds it.
Career: Director of Product Management at a publicly traded lender, Product Director at a national automotive marketplace group, and engineering and front-end architecture before that. Based in Atlanta, Georgia, working with clients anywhere.
Common questions.
What size company is a fit?
The shape matters more than the size. Operationally complex: multi-location, field workforces, layered workflows, or high transaction volume. We work with construction and field service, distribution, property management, veterinary groups, and logistics.
On revenue, a full custom build runs into six figures, so it tends to make sense from around $5M up. Below that, the shorter engagements and ongoing advisory often fit better, and there's plenty of good work there. If you're not sure, ask.
I'm a software company. Is this for me?
Yes, though it's a different engagement. If you sell software and you're stuck on what to build next, who you're really selling to, or how to get it to market, that's fractional product leadership rather than a custom build. There's no revenue requirement for it.
Do you advise, or do you build?
Both. You aren't handed a slide deck and a list of vendors. We work across every stage of product and software development, from strategy and design through engineering and handoff, and across the operational side too: workflow automation, getting systems to talk to each other, and helping your team bring AI tooling into how they build.
How is this different from hiring an agency?
An agency builds what you specify and leaves. We start earlier, deciding what to build and why, and we stay accountable for the outcome rather than the deliverable.
How is this different from hiring a full-time CTO?
At mid-market scale, a full-time CTO is more executive than the problem requires. A fractional CTO gets you senior technical judgment sized to the actual need, without the executive-compensation commitment.
Do I have to start at step one?
No. Enter wherever you are. If you already know what needs building, we'll scope it. If you already have the software and need someone to own it, start with a retainer. Step one exists because most companies aren't sure yet.
What does it cost?
It depends on what we find. A first project is scoped and priced before it starts, and a build is a fixed-scope proposal, so you know the number before any work begins. We'll talk about ranges on the first call once we know what we're solving.
We don't have time for a software project right now.
The cost you're weighing isn't the cost of starting. It's the one you're already paying. Four hours a month on a workaround is more than a week a year, and it never shows up on a report because it's somebody's normal Thursday.
Step one is one to two weeks and most of the work is ours. What we need from you is a few hours from the person who actually does the job.
How fast do we see something real?
Fast. We work prototype-first, so questions get settled with working software rather than documents. In recent client work, the first working tool landed within weeks of the first conversation.
You're one person. What happens when you're busy?
Fulcrum is one accountable person plus a bench: designers, engineers, go-to-market and marketing specialists, and other product leads I've worked with and bring in when the work calls for them. The team scales to the job. What doesn't change is who owns the outcome, and anyone who joins is working to a specification I wrote while I'm still building alongside them.
Builds run one at a time, so a project in progress isn't waiting behind another one.
What happens when the engagement ends?
You keep everything: the code, the documentation, and a knowledge base built during the engagement so your team, or any future vendor, can pick it up cold. Most clients keep a retainer anyway, but nothing about the setup requires it.
Currently taking new work.
Builds run one at a time, never in parallel. That's a focus decision rather than a capacity one, and it's why the build client never waits behind somebody else. Advisory and retainer work runs alongside.
Send a note about where you are and what's not working.
patrick@fulcrumproductworks.com