Skip to content

Current value and roadmap

What this site is being grown into: one place that answers every question a customer or one of us might have. Where it cannot give a definitive answer, it names the person who can.

This site already carries the customer-facing documentation: the PULSE products, the Macola® guides, the release notes and the archive of the 106 source documents they were written from. The plan is to grow it into the firm's resource center, with our own internal material sitting alongside those pages.

Where to start routes you to whichever page you need and covers what using Claude Code well asks of you. This page is the longer answer to why it is worth doing at all.

What nobody has written down

Somebody rebuilds a laptop and needs it working again by the afternoon. The installation files for the VPN are somewhere, and they cannot remember where. Pulse Dashboard has to go back on. That means finding the application folder and knowing what to do with it, which is to put a shortcut on the client executable. It means working out whether the newer features are already deployed on that copy, which server and database to connect to, and how to obtain a license if the database is a new one.

Not one of those is a hard question. Every answer exists, and every answer exists in somebody's head, so getting at them means interrupting whoever has been here longest and hoping they are at their desk. An afternoon's work turns into a day and a half, and none of the time goes on the job itself.

What is missing runs well past setup questions like those. It is the workaround only one person remembers, the reason a particular customer's setup is unusual, the order the steps have to run in, the question that comes up on every implementation. It stayed in our heads because writing it up properly cost more time than anyone had, and writing it up now costs a fraction of that.

The first group is the subscriptions and services we pay for. Most of us have gone looking for one of these at some point and ended up asking whoever was nearest:

  • Google, for email
  • web hosting, for the sites
  • DevExpress, for the developer components
  • Zoom, for meetings
  • TFS, for source control
  • Claude, for the work described on this page

For each one, the entry should name the manager: the person who can add or remove users and change permissions. That is usually the question being asked anyway, because somebody has started or left and an account has to move. Those six are examples rather than the whole set, and most of us could name two or three more without thinking hard.

The second group is the systems themselves. This is what a new developer asks about in the first week, and what a consultant asks again after a year away from a particular install:

  • what servers we have, and what version of SQL each one runs
  • where the databases are, and which databases you should be using
  • where the installation files for the VPN are
  • where the Pulse publishing software is, and where its files are actually stored
  • where the production, test and demo versions of the Pulse applications are

What goes on the site, and what stays in Passwork

Internal material will be shared only with Leahy employees who have signed in, in an area of the site that opens for a Leahy login and for nothing else. The same gate has to cover the Ask the docs assistant, because it answers from whatever the site holds. Once internal pages exist, it must draw on them only for somebody signed in, and answer everyone else from the customer-facing pages alone.

That authentication is not built yet. There is no login on this site today, no restricted area behind one, and no separation between what the assistant will tell an employee and what it will tell a stranger. Everything published here is readable by anyone who finds the address, and anything the assistant can reach it can repeat. That is why the two lists above name the questions and stop short of the answers.

The first internal pages have gone up ahead of the gate. Development environments records the toolchain each product is built with — the IDE, the framework, the component libraries and the SQL Server versions we support. Those pages are written for staff and are listed in INTERNAL-PAGES.md at the root of the repository, which is the checklist for whoever deploys the login. They are excluded from search engines, from the site's own search and from the sitemap, and none of that makes them private: anyone with the address can read them. So the line held on those pages is narrower than the one this section describes. Our own tool and framework versions are published. Customer names, server names, database names and paths are not, and they wait for the gate.

Once there is a login in front of it, the rest follows, and that covers more than people tend to assume: server inventories, environment layouts, who manages which subscription, procedures, the reason a decision went the way it did two years ago.

Passwords and authentication credentials are the exception. They do not go on this site at all. They live in Passwork and they stay there. The resource center should say so on a page, so that somebody hunting for a credential reads one line and opens Passwork instead of asking three people who may not know either.

How the next pages get written

Most of what belongs in the resource center is already being said. It goes into email, into chat messages, and into the transcripts of the meetings we hold every week. Somebody notices that a page is wrong, or out of date, or silent on the thing a customer just asked about, and says so. Today that remark lives in one thread and dies there.

Phase 1: seeding it by hand

This is where we are now, and it asks nothing of anybody except time. Someone who knows the answer opens a session and says it in plain English. Claude drafts the page in the house style, and a person reads it before it publishes. Every page on this site arrived that way, including this one.

There is a queue already. More source documents are waiting to be handed over, the handouts and notes that never made it into the library the first time around. Beyond those sits the technical documentation for our own applications, which follows once their source code is brought into this framework and Claude can read the code alongside the notes and write from both.

The first of that has arrived ahead of the code. Two notes kept in the Pulse Dashboard repository — what the product is and how it is built, and why the data layer works the way it does — were handed over as files and rewritten as pages. That works, and it is not the arrangement we want. A session can only read a repository that is on GitHub, so until the application source is there, every page written from the code depends on somebody remembering to send the file. Once it is there, a session reads the code and the notes together, a page can cite a line a reader can open, and a change to the code can carry the documentation change with it in the same pull request.

Reporting a problem is the same work in miniature. When you find something here that is wrong, stale, missing, or in need of a revision, say so and hand the note over: an email you forward, a message you paste into a session, a paragraph you type yourself. You do not have to edit a page or file anything, and the smallest correction is worth passing on.

Phase 2: connecting email and transcripts

Nothing is reading our meetings, email or chat today. Phase 2 would change that. It is optional, and it is worth doing.

Claude would read the transcript of an internal meeting along with what was written down in email and chat, and compile a list of recommended changes and additions to the resource center: the decision that changed a procedure, the page that is now wrong, the answer somebody gave out loud and nobody wrote down. We would revise that list against the standards documented on this site before anything published. The mechanical part would run on its own, and our job would be reviewing and polishing what came back.

The reason to want it is that we answer questions out loud every week that never reach a page. One meeting where somebody explains why a customer's setup is unusual is a page. So is the half hour spent working out which database a project should point at. At the moment that evaporates, and the same question gets asked again six months later.

The reason to take the decision carefully is that handing meetings, email and chat to any system is a fair thing to have reservations about. People speak differently once they know a recording is being processed somewhere, and those channels carry personal remarks, customer confidences and material that belongs to other people. Anyone uneasy about it is raising a real point, and the terms belong at the front of the project rather than the end: which channels are in scope and which are not, how a conversation gets marked off limits, and who reads the output before it goes anywhere near a page. A transcript would be a source document like any other, and the page that came out of it would still be read by a person before it went up.

If phase 2 earns its place on our own discussions, the same routine could extend to what we hear from customers, and be tied into Synergy, so that a recommendation for a new request, or a change to a request already open, is queued for the right person to approve rather than waiting on somebody remembering to raise it.

What the resource center should be able to tell you

The goal is a resource center that is the definitive place to ask a question, for customers and for our own people alike. It will not hold every answer, and it does not need to. At a minimum it should tell you where the answer lives, or who is most likely to know. It will not hold a password, for instance, but it will tell you the password is in Passwork.

What we get back

Deliverables go out faster. We keep each other better informed, and work carries cleanly from one conversation to the next instead of depending on who happened to be in the room.

The rest of the return is time, and where that time goes is worth deciding on purpose. Some of it covers work already in the queue. The more valuable share goes to customers: helping them get our software configured properly at the start, and learning their business well enough to be useful about it rather than merely responsive. Further out it becomes something we can sell. Advising a customer on putting AI to work in their own operations and their own customer relationships is a service we will be able to offer credibly, because we will have done it here first.

Every one of those pages has to come from the person who knows the answer, and for a good number of them that is you. That is why learning to use Claude properly is worth the time. How this site works and Getting started with Claude Code are how you get what you have been carrying for years onto a page the rest of us can find.

Support & contact

Our team is glad to talk any of this through, including what belongs in the resource center and what does not.