[Paid] Fullstack dev for bidimensionnal navigation


We are a startup of 140+ employees, building a decentralized network of food distribution communities, each community is managed by a Host. We have around 1000 in Europe. We want the Hosts, the Farmers, and the Members to collaborate online.
After a year of internal testing, La Ruche qui dit Oui ! (The Food Assembly in UK) is ready to bring our network on our Discourse.

What would you like done?

We need a fullstack dev to implement a bidimensional navigation feature.

Don’t be afraid, I’ll explain :

  • we want a plugin
  • GPL2 is fine
  • enabling the creation of custom tables
  • either in content or a new kind of pages
  • the table creator configures one tag per column, on tag per line
  • the table is published
  • the table cells contain a list of all the topics which have both tags (column & line)

Alright, an example:

  • I create a table, declaring the tags “TODO” “DO” “DONE” as 3 columns.
  • declaring the tags “DESIGN”, “CODE”, “DEPLOY” as 3 lines.
  • I publish my table
  • I get something looking like
  • the table would be sexy, with hover on links, icons, etc.
             |   TODO      |   DO        |   DONE      |
   DESIGN    |             | 365 896     | 234         |
   CODE      | 845         | 745 312     |             |
   DEPLOY    | 256         |             |             |


  • 365 & 896 are links to the 2 topics with tags DESIGN + DO
  • 234 is a link to the 1 topic with tags DESIGN + DONE
  • 845, CODE + TODO

FYI, this would be a discourse implementation of the practishare methodology.

When do you need it done?

A delivery for September would be swell.

What is your budget, in $ USD that you can offer for this task?

We’re planning a first investment between $2000 & $8000.


I like this because it is very very quirky and different :slight_smile:

Overall, once we have table support this should be fairly straightforward except that keeping the data in the table “fresh” is going to be tricky especially if it is embedded in a post.

How “fresh” do you need the data to be?

  • Always up to date?
  • Can be up to 1 day old?
  • Somewhere inbetween?

Also, security is a concern, what if some “Design/TODO” topics are in a private category?


Daily make sense for us (we want to use it to organize a knowledge base, an lag of 12h average won’t hurt much).
The above Kanban example, which is not our primary use, would be nice to have real-time.
But it’s probably better to start simple (daily), and iterate to speed up refreshing.

I am not confident enough on our needs to give a precise answer, sorry.

  • In a perfect world, each user can only see topics he/she can access, obviously. But I’m pretty sure the code complexity will be overwhelming for a first iteration.
  • In the real & ugly world, we don’t really care some users can see a topic link/title… they won’t be able to access the content anyway. And we say it is the author responsibility to build a table users can browse.
  • In a quick & smart world, we could do : the table only index posts of its own category. That seems fairly easy to achieve, and solves all security concerns. But degrades the feature quite drastically.

It’s an open question, but as the feature is supposed to ease the organisation/navigation between posts, it could be seen as counter-intuitive to put it within a post. Maybe it should be looked at like a new kind of topic listing page…

@sam I was really happy to get your approval on this job and thought to get many candidates. I had a couple only. Is it expected on this category ? Or is there an issue with my proposal ?
Thanks for your advise :slight_smile:

1 Like

Just one or two freelancers getting in touch sounds quite normal. The Discourse ecosystem is growing steadily, but there’s not yet any independent developers who’re making a living off of doing Discourse work 5 days a week. I’d say there’s about 20 regular devs around who could do this kind of job, but their times of availability vary greatly.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.