Business Applications & Integration
Sometimes you don’t need another system. You need the systems you already have to work better together.
Or you need one missing piece.
Marshall Technology helps organizations close targeted technology gaps with practical applications, integrations, dashboards and automation designed around the problem that actually needs to be solved.
There is usually a reason that spreadsheet exists.
- Maybe your CRM does 90% of what you need.
- Your accounting system has the data, but getting useful information out of it is another story.
- Your website collects information, but someone still has to enter it into another system.
- A critical process lives in a spreadsheet because none of your applications handle it quite right.
- Or your team spends hours every week moving information from one place to another.
These are technology gaps.
Spreadsheets, email and manual processes often fill the spaces between what your systems do and what people actually need to accomplish.
Replacing everything may be unnecessary.
The best solution is often the smallest one that solves the problem well.
What are you trying to fix?
“We’re doing this in spreadsheets.”
Spreadsheets are incredibly useful. They also have a habit of becoming business systems without anyone deciding they should.
When a spreadsheet becomes too complex, too important, too difficult to share or too dependent on one person, it may be time for something more purpose-built.
“Our systems don’t talk to each other.”
Information gets exported, emailed, reformatted and entered again somewhere else.
An integration may be able to eliminate much of that work without changing the systems themselves.
“We have the data. We just can’t see it.”
The information leadership needs may already exist across accounting, CRM, operations or other systems.
A targeted dashboard or reporting tool can bring that information together and make it useful.
“Our website needs to do something it doesn’t do today.”
The website itself may be fine.
What’s missing may be registration, a customer portal, payments, document exchange, scheduling, database access or integration with another business system.
Rather than rebuilding the website, extend what it can do.
“We have an old application that still runs part of the business.”
Replacing it may eventually make sense. But first, understand what it does, who depends on it, what condition it is in and what replacement would actually involve.
The right answer may be stabilization, integration, modernization, incremental replacement or eventually something new.
“We have an idea. We just don’t know how to build it.”
Start by defining the problem and the smallest useful version of the solution.
Build that. Put it in front of real users. Learn from it. Then decide what comes next.
Buy it. Configure it. Integrate it. Automate it. Build it.
Those are different answers, and custom development should not automatically be the first one.
If an existing product solves the problem well and the economics make sense, use it.
If you already own the capability but it isn’t configured properly, fix that.
If your systems do what you need but don’t communicate, integrate them.
If the problem is repetitive manual work, automate it.
And when there really is a missing piece, build it.
Marshall Technology can help determine which answer makes sense before anyone starts writing code.
A recommendation to build something stands on its own.
If Marshall Technology recommends an application, integration or automation, you can have us build it, use your internal team, work with an existing technology partner or take the recommendation to another developer.
The recommendation should make sense for the business whether or not Marshall Technology does the implementation.
Custom software doesn’t stay “custom software” when the business starts depending on it.
It becomes part of the operation.
Before Marshall Technology, I spent years designing, building and leading the development of technology around real business operations.
One internal application began as a targeted solution and grew over time into an enterprise operating platform supporting a multi-state organization.
It ultimately included CRM, resident management, billing, HR functions, scheduling, reporting, dashboards, asset management, help desk functions and other operational capabilities. As the platform and the business grew, the development effort grew with it, eventually supported by a four-person development team under my leadership.
I’ve also designed and built specialized web applications supporting registration, competition management, scoring, subscriptions, reporting and other highly specific workflows.
That experience changes how I think about development.
Once a business depends on an application, the conversation becomes much bigger than code.
There are users and data to protect, security and authentication to manage, infrastructure and backups to consider, integrations with other systems, and ongoing support, changes and documentation. Eventually, someone other than the original developer needs to be able to understand it.
The client shouldn’t be trapped by the solution.
Maintainability, documentation, source-code access and ownership, hosting, ongoing support and the ability to hand the application to another developer all need to be considered as part of the project.
The exact terms depend on the engagement, but those questions should be clear before a business becomes dependent on what was built.
A business application should be built with that reality in mind.
Start with the business problem.
Before deciding what to build, we need to understand what is actually happening.
- What are people trying to accomplish?
- How are they doing it today?
- Where does the process break down?
- What systems and data are already involved?
- What do you already own that we can use?
- Is there an existing product that solves the problem?
- Can we integrate or automate instead of replacing?
- And if we build something, what is the smallest useful thing we can build first?
That last question matters.
A successful technology project doesn’t have to be big. It has to solve the right problem.
And when something genuinely needs to be built, start with the smallest useful version, put it in front of real users and learn before making the next investment.
Have something your current technology isn’t solving?
Maybe you know exactly what you need.
Maybe you just know the current process isn’t working.
Either is a perfectly good place to start.
Let’s talk through the problem and determine whether the right answer is to buy, configure, integrate, automate or build.