Starter Site
A multi-page website with a clear contact path.
Ask about Starter SiteWEB SHELL · CONNECTED WEBSITE SYSTEM
A website connected to the tools that keep your business moving.
Scope the website and the necessary connections together, around a clear customer path. The included features are agreed before the build.
PUBLIC SURFACEPRIVATE LAYER
ROUTE COMPARISON01 02 03
Choose what your business needs.
Web Shell
A website with the connections or private workspace your business needs.
You are hereThe Shell
Custom software for a defined business workflow.
Explore The ShellSYSTEM ARCHITECTURE · ILLUSTRATIVE
A useful path from visitor to customer.
01
Public site
The buyer-facing presence: offer, proof, content, and the right next action.
02
Inquiry / account / request
A clear way for a customer to make a request.
03
Private portal or workflow
An agreed space for customers or your team to act.
04
Status, files, approvals, actions, records
See the progress, files, or approvals that matter.
Illustrative example. The connections and features are agreed for each project.
TYPICAL CAPABILITIES
Choose the connections that matter.
- Public marketing website
- Authenticated client or team area
- Role-aware content
- Structured intake
- Document or asset exchange
- Approval workflow
- Status visibility
- Notifications
- Connected forms or data
- Content administration
- Documented operating flow
Possible capabilities; the included features are confirmed in Blueprint or written scope.
PROOF AND REPRESENTATIVE ARTIFACTAPPROVED PUBLIC CASE STUDY ILLUSTRATIVE ARCHITECTURE
Related work and an illustrative example.
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 Web Shell package.
Read the CNW Alliance case studyPublic → request → private workflow → record
The diagram is an illustration, not a delivered client portal.
DATA · ACCESS · OWNERSHIP
The operating boundary is part of the build.
Data and authentication
- Client-owned accounts are used where appropriate.
- User roles and access are confirmed in scope.
- Only the minimum necessary data should enter the public path.
- Credentials are handled outside public forms.
Ownership and processors
- Ownership follows the written agreement.
- Reusable Steelo frameworks remain Steelo property unless explicitly transferred.
- Third-party services remain subject to their own terms and limits.
- No absolute security outcome is promised.
INTEGRATION BOUNDARIES
Connected does not mean universal.
Platform access
The owner must provide the account, permission, and environment required to build responsibly.
API capability
A provider must support the required action at a usable reliability, rate, and permission level.
Lawful data use
The data path, purpose, and retention boundary must be clear before the system is approved.
Maintenance owner
Someone must own provider changes, credentials, content, and future system decisions.
BACKUP · SUPPORT · OPERATIONS
Plan for the work after launch.
Build and acceptance
The approved scope and accepted behavior define what is delivered. Acceptance is separate from future direction or feature requests.
Defect support
The current Terms provide 7 calendar days of defect support after delivery for defects measured against approved scope and accepted behavior.
Hosting and backups
Hosting environment, domain, backup expectations, and provider responsibilities are confirmed in scope. Do not assume they are included by default.
Maintenance and changes
Ongoing maintenance, monitoring, content changes, integrations, and new features require an owner and written scope.
Read the Terms of Service for the current operating boundaries.
FIT / NOT-FIT
A connected system needs a real owner.
Good fit
- The public website and private workflow need to connect.
- Named users or roles exist.
- Information or approvals need structure.
- A decision owner can approve scope.
- Required integrations can be accessed responsibly.
Not a fit
- A simple brochure site is enough.
- No owner can define the workflow.
- Unlimited features are expected.
- Regulated or sensitive data cannot be handled responsibly.
- The request is actually a larger custom product.
PROCESS
A connected website is scoped as a system.
- 01
Snapshot or inquiry
Start with the situation, the public surface, or a defined request.
- 02
Fit review
Confirm the right route, owner, access, and boundary.
- 03
Blueprint when required
Map the system before a larger build is approved.
- 04
Approved architecture
Set roles, data, workflow, integrations, and acceptance.
- 05
Build and acceptance
Implement the scoped system and verify the agreed behavior.
- 06
Launch and support
Launch, then separate defect support, hosting, maintenance, and changes.
FAQ
Questions worth answering before a system decision.
What makes Web Shell different from a normal website?
Web Shell connects the website to a scoped private area or workflow, so customers or staff can complete agreed tasks.
Does every Web Shell include a portal?
No. The written scope determines whether a portal or a smaller connection is needed.
Who can access the private area?
Only the user groups and roles agreed in scope, such as clients, staff, members, or partners.
What systems can it connect to?
Email, forms, CRM or lead records, calendars, storage, analytics, and other providers can be considered when access, API capability, lawful data use, and maintenance ownership are clear.
Who owns the data?
Ownership and licensing follow the written agreement. Client-owned accounts are used where appropriate, reusable Steelo frameworks remain Steelo property unless explicitly transferred, and third-party services remain subject to their own terms.
Is hosting included?
Hosting responsibility, domain work, renewal, backups, and third-party service costs are confirmed in written scope. A Web Shell request does not assume indefinite hosting or backup management.
What support is included?
Build and acceptance, defect support, hosting, maintenance, and ongoing changes are separate operating responsibilities. The Terms describe the current defect-support boundary; ongoing work requires written scope.
When is Blueprint required?
Blueprint is required when the connections, users, or scope need to be defined before a larger build.
Is Web Shell the same as The Shell?
No. Web Shell starts with a public website and adds a scoped private layer. The Shell is a larger custom operating system or product when the work exceeds that model.
Does submitting reserve capacity or collect payment?
No payment is collected on this page. A request starts fit review. It does not reserve capacity, a scheduled week, inventory, or a founding place.
NEXT ROUTE
Start with the decision that makes the build smaller and clearer.
Use Blueprint when the system needs architecture. Use Contact when the requirements are already defined.