Internal working tools
A focused interface for scheduling, approvals, requests, or another repeatable process, shaped around the people responsible for it.
Our capabilities / Custom software
Build around the way your business works.
When a spreadsheet or a patchwork of tools has reached its limits, a small, well-defined application can give the work a more reliable home.
The first decision is whether to configure an existing product or build something specific. Custom software becomes a useful option when the same important requirement keeps forcing workarounds, and your team can take responsibility for a tool that will need care as the business changes.
A good fit when
Start with the friction in your workflow.
People rely on a fragile spreadsheet, repeat the same work in several systems, or struggle to follow a process that existing software does not support well.
What we work toward
- A clear place to do an agreed piece of work.
- Consistent inputs and fewer ambiguous process steps.
- A maintainable foundation with a documented path for future changes.
Specific outcomes and acceptance criteria are agreed for each project.
Before you invest
- Name the requirement an existing product cannot meet and explain the cost of working around it.
- Walk through one complete task with a person who will use the application, including where they get stuck today.
- Identify who will introduce the tool, help colleagues adopt it, and make decisions about future changes.
Possible applications
A few ways this could take shape.
These are illustrative applications to explore, not descriptions of past client projects. The right starting point depends on your process, tools, and constraints.
Connected applications
A defined integration that helps existing systems exchange the information they need, with validation and understandable error handling.
A better workflow interface
Replace an awkward sequence of forms or spreadsheet tabs with a small set of screens that make the next action clear.
An illustrative pilot
Give one approval process a clear home.
Imagine an internal request moving through email and a shared spreadsheet. The requester cannot tell whether it was received, and the reviewer has to reconstruct earlier decisions from several messages.
One useful first version
A first pilot could support one request type, a requester view, and a reviewer view. Required fields, visible status, and a recorded decision would define the useful path from submission to review.
What a review could check
- A representative user can submit a valid request and find its current status.
- Each agreed role can perform its permitted actions, with other actions rejected.
- Missing information and interrupted saves produce understandable feedback without losing an already accepted request.
This example would not automatically include mobile apps, billing, every department's approval rules, or a full migration of old records. Those decisions belong in a separate scope.
This is a hypothetical scope. Your proposal would define the actual deliverables, test examples, and acceptance criteria.
A shared understanding
Know what goes in. Know what comes out.
The final scope is agreed before a build begins. These are the foundations of a useful engagement.
What a scoped project can include
- An agreed user journey, scope, and acceptance checklist.
- A working application or integration for the selected workflow.
- Relevant tests, deployment notes, and a practical handover.
What we need from you
- Examples of the current process and the people who use it.
- A decision-maker for scope and a reviewer for working demonstrations.
- Agreed requirements for access, data, hosting, and ongoing ownership.
A considered starting point
Custom software creates an ongoing responsibility. We consider an existing product or a simpler process change before building, and make maintenance and third-party costs part of the scope discussion.
Plan the investment and the handover
Make the responsibilities as clear as the work.
A proposal should connect the scope to its cost, review points, and operating responsibilities. Added work and its effect on cost or timing need agreement before proceeding.
What shapes the estimate
User roles, screens, integrations, data migration, and acceptance requirements drive the estimate. Prioritizing one complete user journey makes the first release easier to price and review.
Allow for running costs
Hosting, storage, domain services, and licensed tools may have separate running costs. Agree who holds the accounts, pays providers, and authorizes upgrades before selecting a production setup.
Review the work together
Your process owner sets priorities and brings representative users to agreed reviews. Palmetto turns the selected workflow into working screens; together we record decisions and assess requested changes against scope.
Agree what happens next
The proposal should specify source access, ownership and licensing, deployment instructions, and the person responsible for operation. Training, maintenance, recovery arrangements, and future features should be expressly included or scoped separately.
Useful questions
Before we begin.
How do we know whether to build or buy?
Start with the workflow and its non-negotiable needs. If an existing product fits, it may be the better choice. A custom build makes more sense when a specific, valuable requirement remains unresolved.
Can we begin with a small part of the idea?
Yes. A pilot should cover one useful path from start to finish, with clear acceptance criteria. Additional roles, screens, integrations, and edge cases can be considered separately.
What happens after handover?
Ownership, operating instructions, and access are agreed as part of the project. Ongoing care can be scoped where useful, with defined responsibilities, support hours, and limits.
A little preparation
Give a pilot a clear finish line.
Turn a promising idea into a small, reviewable project with a defined outcome, explicit boundaries, and a useful handover.
Read the practical guideMake room for what matters
Start with one useful change.
Tell us how the work happens today, where it gets difficult, and what a better version would make possible.
Describe your application