Employee intranet
A central home for company news, policies, documents, and self-service tools. Structured around how your people search for things, not around your org chart.
004Intranet/Extranet
Intranet and extranet portals your teams actually use
We design and build custom intranets for your employees and extranets for your clients, vendors, and partners. One place for documents, workflows, and internal tools, with access rules that reflect how your organization really works. Built for companies that have outgrown shared drives and generic portal products.
Sftwr004
What we build
What an intranet or extranet project includes
Every engagement covers the full portal: information architecture, access control, integrations, and the internal tools your teams need day to day.
Client and partner extranet
A secure portal where clients, vendors, or distributors log in to see their own projects, orders, invoices, and files, and nothing that belongs to anyone else.
Access control and SSO
Role and permission models down to the document level, with single sign-on against your identity provider such as Microsoft Entra ID, Google Workspace, or Okta.
Document and knowledge management
Versioned document libraries, approval flows, and full-text search so the current version of a contract or SOP is findable in seconds.
Workflow and forms
Requests, approvals, and internal processes as structured workflows: vacation requests, purchase approvals, onboarding checklists, ticket intake, whatever paper or email currently handles.
Integrations with your systems
The portal pulls live data from your ERP, CRM, HRIS, and file storage instead of duplicating it, so employees and partners see one accurate picture.
How we work
From audit to adoption
(4)- 1
Discovery and content audit
We map who needs access to what: departments, roles, external parties, and the documents and processes they touch. This becomes the permission model and the information architecture.
- 2
Architecture and prototype
We define the stack, the integration points, and the security model, then put a clickable prototype in front of real employees and partners before writing production code.
- 3
Build and integrate
Senior engineers build the portal in short iterations, wiring in SSO, your business systems, and migration of existing content. You review working software every sprint.
- 4
Rollout and adoption
We launch in phases, train admins and content owners, and watch usage data in the first months to fix the friction that keeps people on old habits.
Why Webisoft
Why build your portal with us
An intranet or extranet is only useful if people trust it and use it. We treat it as a product with users, not an IT checkbox.
Custom, not a template
Off-the-shelf portal suites force your processes into their model. We build around your permission structure, your workflows, and your existing systems.
Security first
External users on the same platform as internal data demands careful design: tenant isolation, audit logs, least-privilege access, and encrypted data at rest and in transit.
Integration depth
We are a full-cycle engineering studio, so connecting the portal to ERPs, CRMs, and legacy databases is core work for us, not a plugin hunt.
Built to be maintained
Content owners manage pages, documents, and users without developer help. Clean code and documentation mean your team can extend the portal after handover.
FAQ
Common questions about intranet and extranet projects
(4)- An intranet is a private portal for a company's employees. An extranet extends selected parts of it to outside parties such as clients, suppliers, or partners, with each external party seeing only its own data. Many organizations combine both on one platform with strict access separation, which keeps content and integrations in a single place while enforcing different permission boundaries for internal and external users.
- If a standard product fits the organization's processes and integrations, using it is usually the cheaper and faster option. Custom development makes sense when the portal needs deep integration with business systems, external user access with fine-grained permissions, or workflows a template cannot express. A short discovery exercise comparing required workflows against what the product supports out of the box is the standard way to make this call before committing budget.
- A focused first release typically takes three to five months, depending on the number of integrations and how much content needs migrating. Shipping in phases is the norm, so the highest-value sections go live first rather than waiting for the entire platform to be complete. Content migration and permission modeling are the two tasks most often underestimated in these timelines.
- Yes, with the right permission model. External accounts should be isolated by role, organization, and individual record, so a client or partner can only ever see data that belongs to them. Every access should be logged for auditability, and the permission boundaries should be tested deliberately before any external party receives a login. Getting this model right at design time is far cheaper than retrofitting it after a data exposure.
Intranet and Extranet Capabilities
Where We Add Value in Intranet and Extranet Builds
We build internal portals and partner facing extranets that people actually use: fast search, single sign on, and content that stays current because publishing is easy. These are the capabilities that separate a working portal from an abandoned one.
Identity and Single Sign On
We integrate with Azure AD, Okta, or Google Workspace over SAML or OIDC so employees never manage a separate password and offboarding is instant. Group membership drives permissions automatically, which matters most on extranets where a partner leaving must lose access the same day. Session policies and MFA follow your existing security baseline.Granular Access Control
Extranets live or die on permissions: each client or partner sees only their own documents, projects, and people. We model access as roles plus organization scoping rather than per page checkboxes, so administrators grant access in one place and cannot accidentally leak another client's data. Every permission change is logged for audit.Search That Works
Most intranets fail because nobody can find anything. We build search on Elasticsearch or OpenSearch with permission trimming, so results respect access rights, and we index documents, people, and structured data together. Synonyms, recency boosts, and analytics on failed searches keep quality improving after launch.System Integrations
A portal earns daily use by surfacing data from the tools people already have: HRIS records, CRM accounts, ERP orders, ticketing status, shared drives. We build read and write integrations through official APIs with caching so the portal stays fast even when a source system is slow. Each integration ships with monitoring so failures are visible, not silent.Content and Document Workflows
We set up structured publishing with drafts, approvals, scheduled expiry, and ownership, so policies and procedures have a named owner and a review date. Document libraries get versioning, check in and check out where needed, and retention rules that match your records policy. The goal is content a compliance team can trust.Platform Choice Without Bias
Sometimes the right answer is configuring SharePoint or a headless CMS like Wagtail or Strapi, and sometimes it is a custom application because your workflows will not fit a product. We prototype against your three hardest use cases before committing, and we give you the licensing and total cost comparison in writing. We build on either path, so the recommendation is not self serving.
How We Work
How an Intranet or Extranet Engagement Runs
(4)- 1
Discovery With Real Users
We interview the people who will use the portal daily, not just the sponsors, and we audit the current tools, content, and access mess it replaces. The deliverable is a prioritized use case map, an information architecture, and a build versus configure recommendation with costs. This phase typically takes two to three weeks. - 2
Architecture and Access Model
Before visual design, we lock the foundations: identity integration, the permission model, the content types, and which systems feed the portal. For extranets we design the tenant isolation model here, because retrofitting client separation later is the most expensive mistake in this category. You review and sign off on a working authentication prototype, not a diagram. - 3
Build in Releases
We ship the portal in usable slices, starting with the single feature discovery said people need most, often search or a specific workflow. A pilot group uses each release and their feedback reorders the backlog. Content migration runs in parallel with cleanup rules agreed up front, so old junk does not move into the new system. - 4
Launch, Adoption, Handover
Go live includes role based training, a content owner playbook, and analytics dashboards showing usage by section so you can see what is working. We stay through a stabilization period tuning search and fixing friction the pilot missed. Handover means your administrators can manage users, permissions, and content without calling us, though a support agreement is available.
FAQ
Intranet and Extranet Questions Buyers Actually Ask
(6)- It depends on how standard your workflows are. If your needs are document sharing, news, and basic forms, configuring SharePoint or a similar platform is cheaper and we will say so. Custom wins when the portal must embed your actual business processes, serve external partners with strict data separation, or integrate deeply with systems that off the shelf connectors handle poorly. We prototype your hardest use case on both paths during discovery so the decision is based on evidence, including a five year cost comparison with licensing.
- The big three are integration count, permission complexity, and content migration volume. Each system integration adds discovery, build, and testing time, and legacy systems without clean APIs add the most. Extranets cost more than intranets at the same feature set because client data isolation and external identity handling require more engineering and testing. A focused intranet is typically a three to five month effort, extranets and heavy integration builds run longer, and we scope in releases so you get value before the end date.
- Isolation is designed in at the data layer, not enforced by hiding links. Every record carries an organization scope, every query filters on it, and permission trimmed search means a client cannot even see result snippets from another tenant. We add automated tests that attempt cross tenant access on every build, and audit logs record who accessed what. For higher assurance we can separate storage per tenant, and we will tell you when that extra cost is justified.
- Through the official APIs of each system, with an integration layer that caches data so the portal stays responsive and keeps working in read only mode if a source goes down. Writes, like submitting a request that creates a ticket, go through queues with retry so nothing is lost. During discovery we verify API access and rate limits for each system before estimating, because the gap between a vendor's API marketing and reality is a common source of overruns.
- Abandonment is a governance failure more than a technology one, so we build the governance in. Every content area gets a named owner and a review date, and the system nags owners when content goes stale. Publishing is simple enough that non technical staff do it without tickets. Usage analytics show which sections earn attention so you invest where people actually go, and the launch plan seeds the portal with the tools people need daily, because a portal used for one essential task stays alive.
- A scoping call, then a discovery phase of two to three weeks where we interview users, audit current tools and content, and verify integration feasibility. You get an information architecture, a build or configure recommendation with a cost comparison, and a release plan with estimates. That package is yours to keep or to take to another builder. If we continue, the first release is typically in front of a pilot group within the first two months of build.
