Custom enterprise software development: what to require, ask and sign

Custom enterprise software development is building software around one company's processes, together with the controls a larger organization needs: single sign-on, roles, audit logs, data retention, support terms and connections to the systems already in place. It beats off-the-shelf software when your process is how you compete, or when no product covers the work without side spreadsheets.

The build itself follows the stages in our guide to the custom software development process. This guide covers what "enterprise" adds, and how a mid-size company should buy it.

When does custom enterprise software beat off-the-shelf?

Buy when a product covers the work with its own settings: payroll, the general ledger and email rarely need custom software. Build when:

• the process is how you compete, such as how you quote, schedule or serve clients;
• the work crosses several systems and no product owns the whole flow;
• your team keeps spreadsheets beside the software you bought.

Often the answer is both: keep the core systems and build the missing piece, connected as our guide to custom software integration describes. If the system you would replace is old and failing, start with legacy system modernization.

What does "enterprise" add beyond features?

Features are what your people see. The enterprise part is what your IT team and auditors ask about: who can sign in, what each person can do, what gets recorded, how long records stay, and what happens when something breaks or you leave.

It costs little designed in and a lot added later. A guide from CISA, the U.S. government's cyber defense office, and its partners says single sign-on support "should be made available by default at no additional cost," and asks for "high-quality audit logs to customers at no extra charge or additional configuration." Write these down before you ask for a price:

Requirement	Why enterprises need it	What to ask for
Single sign-on	Access ends when IT closes a leaver's account	Open standards, no extra charge
Multi-factor sign-in	Passwords get phished	A phishing-resistant option, required for administrators
Roles	Teams see different records	Roles matched to jobs, and a report of who holds each
Account reviews	Leavers keep forgotten access	Accounts closed on departure, and a scheduled review
Audit logs	Auditors need who did what, and when	A written list of logged events, protected and exportable
Data retention	Records rules set how long data stays	Periods per record type, disposal that reaches backups
Uptime and support	The business stops when the system does	Written availability, response times and maintenance windows
Integrations	Data lives in accounting, HR and the customer system	Which system owns each record, and failure handling
Security review	IT approves new software before launch	Written secure development practices, questionnaire answers
Exit	You may change builders	Full export in a usable format, documentation, handover

How should sign-in and permissions work?

Sign-in. With single sign-on, people use their company account, and access ends when IT closes it. The National Institute of Standards and Technology (NIST) says in its digital identity guidelines (July 2025) that a system at its middle assurance level must offer at least one sign-in option that resists phishing. It also says not to force password changes on a schedule, only on evidence of compromise, and suggests a fresh sign-in at least every 24 hours and after no more than an hour idle.

Roles and accounts. NIST's catalog of security and privacy controls asks organizations to define the allowed account types, approve new accounts, monitor their use, review them on a schedule and "align account management processes with personnel termination and transfer processes." Administrator accounts get "additional scrutiny," and shared accounts are among the types it suggests prohibiting. As an example:

• Roles named after jobs (branch manager, controller, read-only auditor), not people.
• A request and an approval for every new account or role change.
• A quarterly report to record owners of who holds which role.
• No shared logins; each connection to another system has its own account.

What should the audit log record, and for how long?

The NIST catalog's event logging control asks you to choose the events the system logs, explain why that choice is enough "to support after-the-fact investigations of incidents," and review it on a schedule. Its examples include password changes, failed logons and use of administrator rights.

Add what auditors ask about: approvals, changes to amounts, prices or bank details, exports and role changes. Each entry should show who, what, when, the value before and after, and the outcome.

Retention is a separate decision. The catalog says to keep audit records for a period "consistent with records retention policy," and to manage data under the laws and policies that apply to it. Get the periods from your records owner, finance and counsel before the build, make them settings per record type, and plan disposal, which in the catalog covers "originals as well as copies and archived records."

What does your IT team's security review look for?

New software should need IT's sign-off. The CISA guide recommends policies "requiring that IT departments assess the security of software before it is purchased," with any decision to accept a product's risks documented and approved by a senior business executive. Expect questions on:

• Secure development. NIST's Secure Software Development Framework (version 1.1, February 2022) gives buyers terms to state requirements to suppliers. Its practices include archiving what each release needs and a policy for disclosing and fixing vulnerabilities.
• Your data: where it lives, encryption, backups and separation from other clients' data.
• Builder access: who can reach your data, and whether that is logged.
• Outside audits. If procurement requires a report or certificate, say so on the first call.
• Releases: what is tested, and how security fixes reach you.

Which questions should you ask a developer?

Ask every candidate, in writing:

1. Does single sign-on cost extra, and which standards do you support?
2. Can we get a report of who holds each role?
3. Which events does the audit log record, who can change it, and can IT export it?
4. Can retention be set per record type, and does deletion reach backups?
5. Which service levels go in writing: availability, response times by severity, maintenance windows?
6. How do we get all our data out, and what does the handover include?

What should the contract say?

The NIST catalog lists what an acquisition contract should carry, including security and privacy requirements, documentation, who is responsible for what and "acceptance criteria." Also cover:

• Ownership. The contract decides it. Some builders assign the code to the client; others keep it and license its use. Know which you are signing.
• Data. That your data stays yours, how the builder may use it, where it is stored and how it is deleted.
• Service levels. In the catalog's words, service-level agreements "describe measurable outcomes, and identify remedies and response requirements" when they are missed.
• End of support. The secure development framework's examples include "notifying users of the impending end of software support and the date of software end-of-life." Get that notice in writing.
• Exit. A full export in a usable format, documentation and a handover period.

This isn't legal advice: have counsel read it.

How should you run the buying and the first 90 days?

Before you sign:

1. Name one business owner who can decide, plus an IT contact.
2. Write the requirements list from the table with IT, finance and the records owner.
3. Send it with your security questionnaire, and ask for a written proposal: scope, phases, approval rules, service levels and price.

Then, as an example (your scope sets the real dates):

• Days 1 to 30: discovery and design. Map the process with the people who do it; agree roles, logged events and retention periods; sign off the screens.
• Days 31 to 60: first working release. A pilot group uses it with approved test data while IT checks the security answers against the build.
• Days 61 to 90: connect, move and launch. Integrations tested with real records, data moved and reconciled, people trained, then a go or no-go with the record owners.

How does Raileon handle custom enterprise software development?

We build custom enterprise software around how your company already runs: internal tools, client portals, dashboards and integrations, then run them for you. If an existing product fits, we'll tell you on the first call.

It starts with a free 20-minute call with the founder. A written proposal sets out what we'll build, what it connects to, which actions wait for your approval and the exact price, before anything starts. Then we build in stages you can see, train your people, and host, monitor, update and back up what we built.

The build is priced by scope. Monthly care (hosting, monitoring, fixes and updates) starts from $1,999 a month. Cancel any time. Your plan runs to the end of the month you've paid for. No exit fee.

For your IT team: every client's data is kept separate, encrypted in transit and at rest, and backed up daily. Your people sign in with single sign-on through your company account, and the service levels (availability, response times by severity, maintenance windows) are written into the proposal. Support staff use a marked support session to look at your workspace, and its start and end go into an audit log we keep for 24 months. Our terms are plain: Raileon owns the code it builds, and your data stays yours.

FAQ

What is custom enterprise software development?

It is building software around one company's processes, with the controls a larger organization needs: single sign-on, roles, audit logs, retention, support terms and connections to existing systems. Those controls are designed in from the start, not added later.

What should custom enterprise software development services include?

Discovery, design, a build in stages, testing with real records, data migration, training and support after launch. On the enterprise side: sign-in, roles, audit logs, retention, integrations, a security review and a written exit plan.

Is enterprise custom software development only for large companies?

No. A mid-size company with several teams, several systems and an IT review needs the same controls at a smaller scale, so start with one process and build them into its first release.

How long does custom enterprise software development take?

It depends on the scope: how many processes, roles, systems and records are involved. Ask for a schedule in the written proposal, with an early working release your people can try rather than one launch at the end.

What will your IT team ask first?

Bring your requirements list or your security questionnaire. On a free 20-minute call, we'll tell you what we'd build first, or whether a product you can buy fits better.

Book a free 20-minute call