Skip to content
Business Agile
← Work
App · Media monitoring, subscription software · Jul 2017

Jaco

ETAONIS's monitoring product, from paid sign-up to periodic reports.

Key figures

subscription plans at sign-up3
features built for the MVP4
API access method, recommended and chosenephemeral token

ETAONIS was launching Jaco, a news monitoring product. The need was precise: an MVP that stands up commercially, meaning able to take a subscription on day one, not just show a mock-up. Four features were built, each answering one step of a subscriber's journey.

The project in detail

Sign-up happens in two steps, the credentials and the choice of one of the tool's three plans, which can be validated in whichever order suits the user. Payment goes through Stripe, with a coupon system planned from the start, because a launch rarely happens without welcome offers. Search combines a simple bar with an advanced area by sector, geography, date and keywords.

The fourth feature is the one that turns a search engine into a monitoring product. Subscribers record the alerts they expect, from sectors and keywords, and how often they want reports. A dedicated script reads those preferences and sends the alerts and reports. That automation is what means a subscriber no longer needs to come back to the site for the service to be of use.

One architectural point was settled before a single line was written: how the application queries the data API. Two options stood: route requests through Django, which then acts as a relay, or call the API directly from the browser using an ephemeral token identifying the user. The first was quicker to set up, the second cleaner and faster. We recommended the ephemeral token and that is what was built: the repository still carries its token module and its bespoke authentication backend.

The DevOps side mattered as much as the code. We installed a GitLab instance at the client's, moved its code across, set up a staging environment and configured continuous integration so that any change pushed to a given branch deploys automatically. The application is containerised, served by uWSGI behind nginx, with its deployment files in the repository. Training came with delivery, so the team could keep its own chain alive and write its own tests.

That is the model I prefer on an MVP: deliver the product and leave behind a team able to carry on without me.

What was done

  1. 01

    Two-step sign-up with a choice of three plans

  2. 02

    Stripe payment and a coupon system planned from launch

  3. 03

    Advanced search by sector, area, date and keywords

  4. 04

    Alerts and periodic reports sent by a dedicated script

  5. 05

    Direct API calls through an ephemeral token, recommended then built

  6. 06

    GitLab installed at the client's, automated staging and training

Frequently asked questions

Should an MVP already be able to take a payment?

If the model is subscription, yes. On Jaco, Stripe payment and coupons were part of the first scope: a product that cannot take money does not measure real market interest, it measures curiosity.

Should API calls go through your own server?

Not always. On Jaco we compared relaying through Django against calling directly with an ephemeral token identifying the user. The relay was quicker to write, the token cleaner and faster: we recommended the token, and the token is what was built.

What does a client keep after an MVP is delivered?

On Jaco, a GitLab instance installed at their premises, their code moved into it, a staging environment, continuous integration that deploys automatically, and training to write their own tests. The aim was that they could carry on without us.

Other work

A project? Let's talk this week.

A short brief, an answer within 48 hours, a firm estimate after scoping.

Describe my project