Users and roles
Who uses the tool and what each person can do.
THE SHELL · CUSTOM SOFTWARE SYSTEM
Custom software for a defined way of working.
Build a focused tool around the people, information, and decisions it needs to support.
INPUTSWORKFLOWOUTPUTS
ILLUSTRATIVE SYSTEM MODEL
From inputs to a useful operating result.
01
Inputs
Bring the information the work needs into one place.
02
Role-aware workspace
Give each user access to the work that belongs to them.
03
Workflow and decisions
Make the next task or decision clear.
04
Records and notifications
Keep track of progress and what needs attention.
05
Reporting or customer output
Produce a useful view, document, or customer action.
Illustrative system model. The features of a production build are agreed in scope.
USE CASES · FEASIBILITY REVIEW
The route changes with the operating problem.
- Client portal
- Internal operations hub
- Intake and approval platform
- Member or partner workspace
- Service-delivery workflow
- Content or asset operating system
- Custom product interface
These are possible uses. Feasibility and the included features are confirmed before a build is approved.
OPERATING PARTS
A system is more than an interface.
Information model
The information your team needs to work with.
Workflow logic
The core workflow and the decisions it supports.
Integrations
The agreed connections to your existing tools.
Operational ownership
Who will run the tool after handoff.
Acceptance boundary
How you will review and accept the finished work.
BLUEPRINT GATE
Start with BlueprintThe decision comes before the build.
The Shell begins with Blueprint unless an approved equivalent system specification already exists. It defines the project and its ongoing responsibilities before implementation.
PROOF AND REPRESENTATIVE ARTIFACTAPPROVED PUBLIC CASE STUDY ILLUSTRATIVE SYSTEM MODEL
Related work and an illustrative model.
CNW Alliance
A refined identity and bilingual website with a clearer inquiry path. Related work; CNW is not presented as a buyer of this exact software package.
Read the CNW Alliance case studyInputs → roles → workflow → records → output
The model above is an illustration, not a delivered client system.
SECURITY · DATA · OWNERSHIP
The operating boundary is part of the product.
Security and access
- Roles, authentication, and administrative access are defined in scope.
- Credentials stay out of public request forms and marketing surfaces.
- Only the minimum necessary data should enter each workflow.
- Sensitive or regulated data requires a separate suitability decision.
Data and ownership
- Data ownership, licensing, and account control follow written terms.
- Client-owned accounts are used where that creates a cleaner handoff.
- Reusable Steelo frameworks remain Steelo property unless explicitly transferred.
- Third-party providers keep their own terms, limits, and operating obligations.
No absolute security outcome is promised. A responsible system has a named owner and a bounded data path.
HOSTING · BACKUPS · SUPPORT
Who runs the system after launch.
Hosting and domains
Hosting environment, domain work, renewals, provider costs, and account ownership are assigned in written scope.
Backups and recovery
Backup frequency, retention, recovery responsibility, and testing are confirmed when the system requires them. Do not assume they are included by default.
Defect support
The current Terms provide 7 calendar days of defect support after delivery for defects measured against approved scope and accepted behavior.
Maintenance and change
Monitoring, provider changes, content updates, integrations, and new features require an owner and written scope.
Read the Terms of Service for the current operating boundaries.
FIT / NOT-FIT
Custom software needs a real decision owner.
Good fit
- A repeated workflow is costly, unclear, or fragmented.
- Named users, roles, records, and decisions can be defined.
- A decision owner can approve scope and acceptance.
- Required providers and accounts can be accessed responsibly.
- The business can own the system after handoff.
Not a fit
- A clear public website already solves the problem.
- No one can define the workflow or own the decisions.
- Unlimited features are expected without a bounded scope.
- Regulated or sensitive data cannot be handled responsibly.
- The request needs a product team or infrastructure commitment beyond this route.
PROCESS
The system is scoped before it is promised.
- 01
Blueprint
Define the need and the people using the tool.
- 02
Architecture
Agree the core workflow and necessary connections.
- 03
Prototype where needed
Test the hardest assumption.
- 04
Approved build scope
Confirm deliverables, responsibilities, and acceptance in writing.
- 05
Implementation
Build and review the agreed tool.
- 06
Acceptance and launch
Accept the work and complete the handoff.
- 07
Support and maintenance
Follow the agreed support and maintenance terms.
FAQ
Questions worth answering before a custom-system decision.
What is The Shell?
Custom software built around a defined business workflow, for an internal team or its customers.
How is The Shell different from Web Shell?
Web Shell begins with a public website and adds a scoped private portal or workflow layer. The Shell is the larger custom system model for deeper roles, records, integrations, and product behavior.
What kinds of systems are a fit?
A client portal, team workspace, or focused workflow tool may fit after feasibility review.
When is Blueprint required?
Start with Blueprint unless an approved equivalent specification already defines the build.
What does feasibility review look at?
Whether the tool can meet the agreed need within the available scope, access, data constraints, and ongoing responsibilities.
Who owns the data and system?
Ownership, licensing, account control, and handoff follow the written agreement. Client-owned accounts are used where appropriate. Reusable Steelo frameworks remain Steelo property unless the agreement explicitly transfers them, and third-party services remain subject to their own terms.
What are the security boundaries?
Roles, authentication, data minimization, credentials, providers, backups, and operational access are defined in scope. The Shell does not promise absolute security, and sensitive or regulated data requires a separate suitability decision before work begins.
Who handles hosting, backups, support, and maintenance?
Hosting environment, domain work, backups, defect support, monitoring, maintenance, provider costs, and future changes are assigned in written scope. A request does not assume indefinite operations coverage.
Is The Shell a fit for a simple public website?
Usually not. If a public website is enough, Starter Site or Web Shell may be the clearer route. The Shell is for a defined operating problem that needs custom system behavior.
Does a request reserve capacity or collect payment?
No. A request starts fit review. It does not reserve capacity, a scheduled week, inventory, or a founding place, and no payment is collected on this page.
NEXT ROUTE
Make the system decision legible before the build gets expensive.
Use Blueprint for architecture and feasibility. Use Contact when the requirements are already defined.