Usivity vs building it in-house
Build what only you can build. Let users personalize the rest.
How one-off customer requests compare when engineering builds them, as tickets, configuration screens or per-customer code, and when users make them in plain language with Usivity.
The short answer
Build it in-house when the change touches your data, business logic or permissions, or every customer needs it.
Use Usivity when a user wants the product to look or work differently for them: a hidden column, a renamed label, a highlight.
One user or a whole account. Your team writes a change once and sends it to the account’s users, so nothing is set up user by user.
No ticket, no release. Changes take seconds and leave your code untouched.
Side by side
Building it in-house and Usivity, compared.
The same customer request, handled two ways.
| Question | Building it in-house |  Usivity |
|---|---|---|
| What it is | Your engineers build the change: a ticket in the backlog, a new setting on a configuration screen, or code for one customer, such as a branch, a fork or a customer-specific flag. | Users ask for a change inside your app, in their own words, and it appears for them. Your team can also send changes from the Usivity portal. |
| Personalized for each user or account? | Rarely. Changes usually ship to everyone, or to one account through a setting or custom code. Almost never to one person. | Yes. Each user gets their own changes, and your team can send one change to a whole account. |
| Who makes the change | Engineering, once product has prioritized it. Customer Success or implementation usually files the request. | The user who wants it. Or your Customer Success, implementation or product team, from the portal, with no code. |
| Time to change | As long as the backlog and the next release take. | Seconds for the user who asks. A change your team sends is there on the user’s next visit. |
| Engineering effort (code) | Very high effortDesign, build, test and release each change, then maintain it. A configuration screen is a feature in itself. | Low effortOnce: one script tag and a server-signed user identity. None per change. |
| Team effortIntake, sizing, prioritization, escalation, testing, upkeep | Very high effortEvery request is taken in, understood, sized, prioritized and often escalated before any code. Then tested, released and carried forward. | Low effortUsers ask for what they want and get it. Your team writes account setups in the portal, with no ticket to size. |
| What your team learns | What reached a ticket. Requests that never became one are lost. | Every request, in the user’s own words, including the ones Usivity couldn’t do. Reports show what is still on after 14 days, by account. |
| Risk to your code and data | Every one-off is code to carry forward. Forks drift from the main product, and each setting adds combinations to test. | None to your code. Personalizations change presentation in the user’s browser, inside the zones you choose, and never write to your backend. Any one switches off in one click. |
Which to choose
Some requests belong with engineering. Most one-offs don’t.
Usivity changes how your product looks and shows data for someone. It never changes your data or your logic, so some requests should stay with your engineers. Here is how to tell them apart.
Data and logic
It changes data or business logic.
It creates, updates or deletes records, changes a calculation your business relies on, or alters a workflow’s rules.
Permissions
It’s about who can see or do what.
Usivity works within your authorization and can’t grant access a user doesn’t already have.
Common need
Every customer needs it.
When the same change comes up at account after account, build it into the product as the default.
New capability
It’s a new module, integration or API.
Usivity shows live data only from the API endpoints you register.
Contracts
It’s written into a contract.
A behavior a customer’s agreement requires belongs in your product, tested and released like the rest.
Personal fit
One person wants it.
A sales lead wants deals over $50k highlighted. A manager wants the team’s numbers in one table.
Speed
It shouldn’t wait for a sprint.
Small requests sit behind roadmap work. With Usivity, the user has the change in seconds.
Accounts
An account wants its own setup.
Your team writes the labels, columns and views once and sends them to the whole account.
One product
You want one product, not many.
Every account runs the standard product. No fork, branch or per-customer setting to maintain.
Learning
You want to know what customers need.
Every request is recorded, including the ones Usivity couldn’t do: a direct signal for the roadmap.
Undo
It must be easy to undo.
Users switch any personalization off themselves, and one switch in the portal turns Usivity off for everyone.
Who does what
Engineering keeps the roadmap. Users get the rest.
With Usivity in place, each kind of request goes to whoever can answer it fastest.
- 1
Users personalize their own view
Columns, labels, highlights, totals, filters and charts, asked for in their own words.
- 2
Your team sends the setup
Customer Success and implementation send a change to one user or a whole account, without a ticket.
- 3
Engineering builds the product
New capabilities, data and logic, with Reports showing which requests deserve a place on the roadmap.
Frequently asked questions about Usivity and building it in-house.
Does Usivity replace our engineering team?
No. Usivity handles requests to change how the product looks and shows data for someone. Records, business logic and access stay with your engineers, who get fewer one-off tickets.
Can Usivity take some front-end work off our team?
For small changes, often. Hiding or reordering columns, renaming labels, formatting numbers, highlighting rows, or adding a total, a filter or a chart are requests users can make for themselves instead of filing a front-end ticket. Your front-end and UX people keep the product itself: its design, its components and anything every customer sees.
How much engineering does Usivity need?
One script tag in your app and a server-side HMAC-SHA256 signature of each user’s ID and email, done once. The tag takes minutes, and allowing your domains and choosing zones takes an hour or two. After that, no change needs code or a release. The only upkeep is keeping zone selectors current when you redesign a screen.
Should we stop building configuration screens?
Not for settings that change what your product does for an account; those belong in your product. For preferences about how it looks and shows data for one person, such as which columns show or what a label says, Usivity can take the place of a settings screen.
How do we know which one-off requests to build into the product?
Reports show what customers change most, how many people and accounts made each change, what’s still on after 14 days, and what the product couldn’t do yet. A change that sticks across accounts is a candidate for your default product.
Compare
Other comparisons.
The other ways teams handle requests to change how the product looks and shows data.
All comparisonsYour customers get a product that fits. Your roadmap stays yours.
In ten minutes we’ll show you what your customers can change on their own, and what your team never has to build.
Book a 10-minute demo
We reply within one business day.
You’re booked.
We’ll reach out within one business day to confirm your 10-minute demo.