PeerPort

Snapshot

The problem: enterprise collaboration, priced for enterprises

By the end of the 2000s a company of eight people could already buy web conferencing, shared calendars, document management and task tracking. What it could not buy was all of that in one place, behind one login, priced for eight people. The tools that did everything were sold to enterprises with procurement departments, and the tools that were cheap did exactly one thing and did not talk to each other.

PeerPort was built for that gap. The idea was a private, secure community per client — a walled space where a distributed team could hold a meeting, assign an action item, argue about a document and keep a calendar, without any of it leaking to anyone outside the walls. Because the customers were small businesses rather than IT departments, the platform ran on a SaaS model with effectively no setup: a client signed up and their community existed. Nobody was going to install anything.

The client also wanted something most collaboration products of that era deliberately avoided. Communities had to be able to reach each other. A business needed to extend membership to its own customers and partners, and resellers and agents needed a route into the platform to sell it on. So the requirement was not one secure box. It was a lot of secure boxes with controlled doors between them.

The decision that shaped everything: build on a CMS

The instinct at the time, when a client described a product like this, was to build it from scratch — a framework, a database schema, and a very long runway. We argued for Drupal instead, and that single call determined the shape of everything that followed.

The reasoning was narrow and specific. Drupal’s community and group handling was, at the time, genuinely excellent: memberships, roles, per-group permissions, and content that belonged to a group rather than to the site were all solved problems in it. Those were not incidental features of PeerPort. They were the product. Rebuilding that layer from scratch would have consumed most of the budget before the client had anything they could sell, and it would have produced a worse version of something that already existed and was already being hardened by thousands of other sites.

Choosing an existing platform is not a shortcut, though, and we should be honest about the bill. You get the hard parts free, and in exchange you spend the rest of the project fighting the framework everywhere your product is not what the framework expected. Drupal in that era knew how to run a community; it had no opinion whatsoever about billing one, about reselling one through a channel partner, or about letting two of them share data under controlled conditions. Every commercial requirement in the specification landed outside what the platform was designed to do.

So the work split cleanly in two. The community plumbing came from Drupal, and everything that made PeerPort a business rather than a forum was written as custom modules on top of it — registration, payment handling, community provisioning, reseller and agent access, and the cross-community sharing that let one client’s space reach another’s.

We would make the same call again, with one caveat worth stating plainly: this only works when the framework’s strength sits at the center of the product rather than at its edge. Had PeerPort been primarily a billing system that happened to have discussion boards, Drupal would have been the wrong substrate and the same decision would have been a slow-motion mistake.

What we built

Every module sat behind authentication. There was no anonymous view of anything, no public profile, no shareable link that worked without a login — a constraint that sounds obvious now and was a genuine design position then, when most social software was racing in the opposite direction.

For members:

• Profiles that worked as virtual business cards, with presence — if someone was logged in, you could see it and reach them directly
• Web and audio meetings through an integrated conferencing service, started on the spot or scheduled, with conference calls for up to fifty members
• A document library with commenting, so a file and the argument about it stayed together
• Action items with priorities, owners, and email notification on assignment
• Community-wide messages open to replies, plus private member-to-member messaging and chat
• A shared calendar any member could post events to and invite others

For the business running the community:

• Community provisioning with no setup step for the customer
• Membership extended to a client’s own customers and partners, inside the same secure boundary
• Cross-community sharing, so two mutual communities could exchange information under controlled conditions
• Reseller and agent access, giving the platform a channel to sell through
• RSS and ATOM feeds pulled in from outside sources, so a team’s space carried the industry news it cared about
• Contact import for invitations, instead of typing addresses by hand

The time zone problem

One requirement looked trivial in the specification and turned out to be the fiddliest thing in the build. A member in one country schedules a meeting. Every other member has to see it in their own local time, correctly, including across daylight saving transitions that different countries apply on different dates for different reasons.

You cannot solve this with an offset stored against a user. An offset is a fact about a moment, not about a place, and a meeting scheduled six weeks out may fall on the other side of a clock change. We integrated a world time zone database so the platform reasoned in zones rather than offsets, storing meeting times in a single canonical form and resolving them per member at display time.

This is the kind of detail that never appears in a sales deck and quietly decides whether a product is trusted. A collaboration tool that puts a team on a call at the wrong hour once has spent its credibility, and no feature added later buys it back.

What it delivered

• A sellable product rather than a prototype — a platform the client could market to small and mid-sized businesses and provision without engineering involvement
• A channel to sell through, with reseller and agent access built into the platform rather than bolted on later
• Budget spent where it differentiated: because the community layer was inherited rather than invented, development money went into the commercial features nobody else had built
• A working relationship that outlasted the launch and continued into the ordinary, unglamorous business of running software people depend on

That last part is the one we are actually proud of. The engagement was described in Phil Simon’s book The New Small (Motion Publishing, 2010), which examined how small companies were using technology in ways that had previously required an enterprise budget. Macronimous appears there as the offshore development partner behind the platform, in an account of how an American software company came to choose an Indian development firm and why it kept working with one.

PeerPort no longer trades. That is the ordinary fate of most software companies and it takes nothing away from the engineering, but we would rather say so than quietly imply an active client.

The takeaway

The most valuable thing we did on PeerPort was talk the client out of building something. A development partner paid by the hour has an obvious incentive to agree that yes, this needs to be written from scratch, and yes, it will take a while. The better answer was to identify the one part of the product that already existed in mature form, take it, and spend the client’s money only on the parts nobody had built yet.

More than fifteen years later the platforms have changed and the judgment has not. Most projects that reach us contain a component that is genuinely novel and a larger component that is a solved problem wearing a new name. Knowing which is which, before the estimate is written, is most of the job.

Building a platform and unsure what to buy versus build? Tell us about it, or see our custom web development services.

We at Macronimous had opportunities to work with simple websites to large scale web applications for clients across the globe since 2001. We have developed Web apps like CRM, Custom CMS, Payroll. Accounting, Hospital Management, Video conferencing, SaaS-based apps, and many more. We have several web development case studies to share with you.

We would love to capture all of them and place them here, But due to multiple restrictions such as time and confidentiality – we restrict ourselves with a few that we could share here as client project case studies.