Philadelphia Media, Pennsylvania

Customer apps and portals built around one useful task.

Assessment and done-with-you concierge are the starting offer. Occasionally the workflow calls for something a customer opens themselves. An app or portal would be a separately scoped project, not the main product or something included in concierge.

We start with that customer action, compare the options, and agree the scope before development. A better mobile website or an existing tool may be the right answer instead.

App and portal projects need their own written scope and commercial terms. Start with a fit conversation, not a commitment to build.

What we look at before anyone builds

The first question is what one thing a customer would open it to do. Not five things. One repeated action, done by people you can name, often enough that having it on a home screen is worth the trouble of putting it there.

Then we look at what already exists. A page that works properly on a phone, the booking or payment tool you are already paying for, the portal your vendor ships and nobody turned on. Those are cheaper, faster, and easier to walk away from. If one of them does the job, that is the recommendation, and it is a short conversation.

An installable app earns its keep when the customer comes back often, needs it to work with a bad signal, or needs something a browser tab cannot do. If none of that is true for your shop, building one is buying a maintenance bill.

What we will not do

We will not promise a store approval or a launch day. Stores decide on their own schedule and change the rules without asking us.

We do not move client money. Payment handling and protected health information are outside this offer.

We do not handle protected health information or provide regulated advice. Data access and responsibilities are defined before work starts.

We will not sign customers up for notifications they did not ask for. If it sends messages, people opt in, choose what they get, and can disable optional notifications through clear controls.

How it would go

Scope, fees, milestones and cancellation terms are agreed in writing before work begins.

  1. Fifteen minutes on what it is for A free 15-minute fit conversation based on written context. The paid 45-minute workflow assessment and report are separate. Detailed app feasibility and development require their own scope.
  2. A written scope before a line of it exists One journey, a short list of what is in, a plain list of what is out, what has to be true for it to work, and the standard we are both agreeing counts as finished. Cost and timing get written down here, after we know the shape of it, not before.
  3. Built, then checked by someone who did not build it Real devices, wrong inputs, dead connections, and somebody trying to open a page they should not be allowed to open. Anything serious gets fixed and rechecked before you are asked to look at it.
  4. Yours, on your accounts You approve it, it goes out under your own store and domain identities, and the source, data export and exit arrangements are defined in the agreement. What we keep supporting, and what falls outside that, is written down rather than assumed.

The parts people find out about too late

Ownership is settled first

Domain, store account, code, and the list of everything it depends on, all under names you control. Written down before the work, not negotiated after it.

Connections have to be permitted

Your other software has to publish a documented way in, and your agreement has to allow it. We prove that against a test system before it becomes part of the plan.

Customer data has a written path

Where it goes, who can read it, how long it is kept, how it gets deleted, and how it comes back if something breaks. No keys or passwords living inside the thing customers download.

Messages are opt in

Nobody gets enrolled in anything by installing. People choose what they hear about, and the controls for turning it off are tested before release.

Checked, not vouched for

Somebody other than the builder tries to break it on real devices. Our own say-so that it works is not evidence, and it is not what you are paying for.

Upkeep is named, not implied

Which phones and which versions we keep it working on, who you call when it is down, what a change costs, and how you take the whole thing elsewhere. Nobody is promising unlimited anything.

Common questions

Do I need an app, or is this a website problem?

It may be a website problem. An app earns its place when the same person does the same thing often enough to want it on a home screen. Twice a year is not that.

Who owns it?

You do. Domain, store account, and code under your names, with the exit written down before anyone starts.

Can it connect to the software we run?

Only if the vendor documents a way in and your contract allows it. We test that first. A vendor having a website proves nothing about access.

Will it get into the stores?

The stores decide, under your developer account, against whatever their rules are that week. We will not sell you a date or an approval.

What does it cost?

We agree on scope, timing and commercial terms in writing before work begins. An app is a separate scope from assessment and concierge.

What counts as finished?

The customer journey, integrations, supported platforms and acceptance tests are agreed in writing. A private concept is not a production-ready application.

Start with the same fifteen minutes.

Book the fit call and say in the written question that this is about something your customers would open. The call is still free and still fifteen minutes. Scope and commercial terms for an app or portal are agreed in writing after we have both looked at whether it should be built.