diff --git a/README.md b/README.md
index c04323a..2dec578 100644
--- a/README.md
+++ b/README.md
@@ -2,18 +2,21 @@
# Technology Stack
-The software and systems we use to build the **`dwyl`** platform.
+The software and systems we use to build **`@dwyl`**.
-
+
+
+ Contents [click to expand]
+
- [Technology Stack](#technology-stack)
- [Why?](#why)
- [What?](#what)
- [The `PETAL` Stack](#the-petal-stack)
- [**`Phoenix`**](#phoenix)
- - [`Phoenix` the "Most Loved" Framework in 2022](#phoenix-the-most-loved-framework-in-2022)
+ - [`Phoenix` the "Most Loved" Framework](#phoenix-the-most-loved-framework)
- [**`Elixir`**](#elixir)
- [`Elixir` is `#2` in 2022](#elixir-is-2-in-2022)
- [**`Tailwind CSS`**](#tailwind-css)
@@ -50,15 +53,19 @@ The software and systems we use to build the **`dwyl`** platform.
- [Other Tech/Tools?](#other-techtools)
- [How to Propose `NEW` Tech/Tools?](#how-to-propose-new-techtools)
+
+
+
# Why?
-As a ***team of people***
-using technology
+As a ***team of people***
+using technology
to **_make_ digital products**,
it's _essential_ to **be _unambiguous_**
about the **stack/tools** we use,
-**so that _everyone_** is **clear**
-what we _all_ need to master.
+**so that _everyone_** is **clear**
+what we _all_ need to
+[**master**](https://www.google.com/search?q=definition+of+mastery).
> _If **anything** is **unclear** or you have **any questions** please_
-[***ask***](https://github.com/dwyl/technology-stack/issues).
+[***ask***](https://github.com/dwyl/technology-stack/issues).
+We are always happy to answer tech stack related questions.
+But please make sure you read the whole doc first.
# What?
-This document + diagrams _describe_
+This document + diagrams _describe_
the full "**`PETAL`**" Technology Stack
we use for **`dwyl`** products/projects.
@@ -84,12 +93,12 @@ and ***world-class quality***!
-"PETAL" is an acronym1
+"PETAL" is an acronym1
for the following elements:
### **`Phoenix`**
-**`Phoenix`** is a Web Application Framework
+**`Phoenix`** is a Web Application Framework
that does not compromise
on speed, reliability or maintainability!
**`Phoenix`** is the "_successor_"
@@ -103,16 +112,21 @@ The list of ***benefits*** Phoenix has over
Please see:
[dwyl/**learn-phoenix-framework**#our-**top-10-reasons**-why-phoenix](https://github.com/dwyl/learn-phoenix-framework#our-top-10-reasons-why-phoenix)
-#### `Phoenix` the "Most Loved" Framework in 2022
+#### `Phoenix` the "Most Loved" Framework
-`Phoenix` tops the list of "Most Loved" Frameworks
-on the 2022 StackOverflow Community Survey ❤️
+`Phoenix` tops the list of "**Most Loved**" Frameworks
+on the
+[2025 StackOverflow Community Survey](https://survey.stackoverflow.co/2025/technology#2-web-frameworks-and-technologies). ❤️
+This is the **3rd year in a row**.
https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies
+
+
+
### **`Elixir`**
**`Elixir`** is the _functional_ programming language
@@ -291,29 +305,39 @@ while developing our [`app`](https://github.com/dwyl/app).
1. `Github Pages` deployment:
[dwyl/learn-**github-pages**](https://github.com/dwyl/learn-github-pages)
-
### Our `MVP`
We have built a fully working MVP version of our App!
Check it out at
[dwyl/**mvp**](https://github.com/dwyl/mvp)!
-
## Database?
-The _reason_ we do not _specify_ our Database
-in the "PETAL" Acronym is
-that **`Phoenix`** allows us
-to use **_any_ Relational Database**.
-
-By _abstracting_ the data layer using "Ecto" the application is "_decoupled_"
+The _reason_ we do not _specify_ our Database
+in the "PETAL" Acronym is
+that **`Phoenix`** abstracts its'
+database access via
+[`Ecto`](https://phoenix.hexdocs.pm/ecto.html)
+to provide built-in support
+to the following **databases**:
+
+* `PostgreSQL` (via [`postgrex`](https://github.com/elixir-ecto/postgrex))
+* `MySQL` (via [`myxql`](https://github.com/elixir-ecto/myxql))
+* `MSSQL` (via [`tds`](https://github.com/livehelpnow/tds))
+* `ETS` (via [`etso`](https://github.com/evadne/etso))
+* `SQLite3` (via [`ecto_sqlite3`](https://github.com/elixir-sqlite/ecto_sqlite3))
+
+By _abstracting_ the data layer
+using "Ecto" the application is "_decoupled_"
from the database.
-This means that if a client _asks_ us to deploy to MySQL or
-Microsoft SQL Server
+This means that if a client _asks_ us to deploy to `MySQL` or
+`Microsoft SQL Server`
(_e.g. because they already have in-house capability
for maintaining one of these databases_)
-we can easily accommodate that
+we can easily accommodate that
without re-writing _any_ of the `Phoenix` app!
+Changing a couple of lines of configuration
+is all that is needed.
### We _Prefer_ `PostgreSQL`
@@ -350,9 +374,16 @@ is because the ***community*** is _superb_.
There is a great "_bank_" of _answered_ questions on
[StackOverflow](https://stackoverflow.com/questions/tagged/postgresql)
and new questions get answered _fast_.
+
+From 2023 to 2025 `Postgres` has remained
+the **most used** and **most desired** Database:
+[survey.stackoverflow.co/2025/technology#2-databases](https://survey.stackoverflow.co/2025/technology#2-databases)
+46.5% of respondants use `Postgres`
+more than double `MySQL` (20.5%).
+
## Operating System?
-A _"traditional"_
+A _"traditional"_
[**LAMP** stack](https://en.wikipedia.org/wiki/LAMP_(software_bundle))
includes the **Linux** Operating System
in the _name_.
@@ -795,26 +826,27 @@ and reduce the chances of success.
## Other Tech/Tools?
-We have written about
-our choice of programming language _extensively_ in:
-[learn-elixir/issues/102](https://github.com/dwyl/learn-elixir/issues/102).
+We have written _extensively_ about
+our choice of programming language in:
+[learn-elixir#102](https://github.com/dwyl/learn-elixir/issues/102).
+
+Our use of **`Elixir`** is for a **_very_ specific reason**:
+we are building **fault-tolerant realtime systems**.
+For the type of App we are building,
+**`Erlang/OTP`** is the **_undisputed_ king**
+on the **server side**.
-Our use of **`Elixir`** is for a very specific reason:
-we are building fault-tolerant realtime systems.
-For the type of App we are building,
-`Erlang/OTP` is the _undisputed_ king
-on the server side.
We _could_ use almost any other language/framework,
but it would be a _lot_ more work for an inferior result.
-If we need to build a **_specific_ feature**
-requested by a person _using_ our product,
-then we will **100%** consider a technology
+If we need to build a **_specific_ feature**
+requested by a person _using_ our product/service,
+then we will **100%** consider a technology
that enables us to deliver it.
## How to Propose `NEW` Tech/Tools?
-The way to _propose_ a specific tech/tool
+The way to _propose_ a **specific tech/tool**
is simple:
[open an issue](https://github.com/dwyl/technology-stack/issues)
describe how the tech/tool
diff --git a/flutter.md b/flutter.md
index a78af55..09354d1 100644
--- a/flutter.md
+++ b/flutter.md
@@ -2,14 +2,14 @@
# `Flutter`
-**Creative technology**
+**Creative technology**
is **_constantly_ evolving**.
There is always
-a **`new` way**
-of ***solving*** an
+a **`new` way**
+of ***solving*** an
**old problem**
-and in some cases
-**_significantly_ simplifying**
+and in some cases
+**_significantly_ simplifying**
the solution.
[](https://twitter.com/nelsonic/status/913811339709173760?s=20)
@@ -58,12 +58,11 @@ of which technology/language/framework
we should or shouldn't use is:
**What are _problem_ are we _trying_ to _solve_?**
-
-The last time we (_informally_) looked at `Flutter` in early 2018,
-it did _not_ meet all our needs for a UI framework.
-At the time, it was focussed on Android,
+When we (_initially_) looked at `Flutter` in early 2018,
+it did _not_ meet all our needs for a UI framework.
+At the time, it was focussed on `Android`,
didn't support Web/PWAs
-and only had partial/beta support for IOs.
+and only had partial/beta support for `IOs`.
In the last couple of years `Flutter` has seen _rapid_
development both from the _army_ of **Google** Developers
@@ -74,17 +73,18 @@ Google is using `Flutter`
for several of their cross-platform Native Mobile Apps
including **Google Adds** (_their main money maker_)
and **Google _Pay_** their popular global payments platform.
-See:
+See:
[flutter.dev/showcase](https://flutter.dev/showcase)
[](https://flutter.dev/showcase)
-There are _thousands_ more examples and more each day!
+There are _hundreds of thousands_ more examples
+and hundreds more published each day!
-It's almost certain that you are _already_ using an App on your Smart Phone
-that was built with `Flutter` whether you know it or not.
+It's almost certain that you are _already_ using an App on your Smart Phone
+that was built with `Flutter` whether you know it or not.
For a community list of Apps built with `Flutter`
including many Open Source ones, see:
@@ -198,65 +198,80 @@ All the _practical_ detail is there.
# Background
-We are building our App:
+We are building our `App`:
[dwyl/app](https://github.com/dwyl/app).
-We selected **`Phoenix`** for the Backend
-because we find **`Elixir`** easy to read, reason about and write.
-(far more so than other major programming languages).
-More detail in:
-[learn-elixir/issues/102](https://github.com/dwyl/learn-elixir/issues/102)
-The data we are storing is _relational_ in nature.
-We are creating `items` of `text`
-that have an _unlimited_ length.
-We want to apply meta data to those `items`
-and create rich interactions around them.
-We will have _many_ useful features in the App
-but the core will be `items`, `timers`, `lists` and `people`.
-
-As a _small_ team with finite resources
-(_and no desire to "raise" money from outside investors_),
-we want to maximise our efforts
-to build the App that _most_ people want/need.
-We are focussing on building the Web App initially
-because the web is universally accessible.
-_Many_ companies have focussed their initial efforts on `iOS`
-because it's the _easiest_ platform to target,
-`iOS` users have more disposable income
+We selected **`Phoenix`** for the Backend
+because we find **`Elixir`** easy to read, write
+and reason about.
+(far more so than other major programming languages).
+More detail in:
+[**learn-elixir**](https://github.com/dwyl/learn-elixir/#key-advantages-)
+The data we are storing is _relational_ by nature.
+We are creating `items` of `text`
+that have an _unlimited_ length.
+We want to apply `metadata` to those `items`
+and create rich interactions around them.
+We will have _many_ useful features in the `App`
+but the core will be:
+`items`, `timers`, `lists`, `people` and `groups`.
+
+As a _small_ team with finite resources
+
+we want to maximize our efforts
+to build the `App` that _most_ people want/need.
+We are focussing on building the **`Web App`** initially
+because the web is universally accessible.
+_Many_ companies have focussed their initial efforts on `iOS`
+because it's the _easiest_ platform to target,
+`iOS` buyers have more disposable income
and are more likely to _pay_ for apps.
> "_Making an App for `iOS` is Faster and Less Expensive_".
-> "_`Android` users tend to be
-> less willing to pay for apps than `iOS` users,
-> so free apps with in-app ads are more common._"
+> "_`Android` users tend to be
+> less willing to pay for apps than `iOS` users,
+> so **free apps** with **in-app ads** are more common._"
https://medium.com/@the_manifest/android-vs-ios-which-platform-to-build-your-app-for-first-22ea8996abe1
-> There are fewer iOS devices to target and test on which dramatically shortens dev timelines.
-e.g in 2022 there are only **7 supported screen sizes** for iPhone:
-> + 4" - iPhone 5S and SE (old screen size but still used by [tens of millions](https://deviceatlas.com/blog/most-popular-iphones) people)
-> + 4.7" - iPhone 6, 7, 8 and SE 2020 & 2022
-> + 5.42" - iPhone 12 & 13 Mini
-> + 5.5" iPhone 6 Plus, 7 Plus and 8 Plus
-> + 5.85" - iPhone X, XS and 11 Pro
-> + 6.06" - iPhone XR, iPhone 11, 12 & 13 Pro
-> + 6.46" - iPhone XS Max and iPhone 11, 12, 13 Pro Max
-See: https://en.wikipedia.org/wiki/List_of_iOS_devices
-The _full_ device feature compatibility matrix
-is lets developers see _exactly_ what features are available for all iOS devices (including all iPads): https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
-
-> In **2015** there were _already_
-> "_more than **24,000 different `Android` devices**
-> from 1300 brands_"
+> There are fewer iOS devices to target
+> and test on which dramatically shortens dev timelines.
+e.g in 2026 there are only **8 supported screen sizes** for iPhone:
+
+> + 4.7": iPhone SE (2nd & 3rd generation)
+> + 5.42": iPhone 12 & 13 Mini
+> + 5.5": iPhone 6 Plus, 7 Plus and 8 Plus
+> + 5.85": iPhone X, XS and 11 Pro
+> + 6.06": iPhone 11, 12, 13 Pro, 14 Pro
+> + 6.3": iPhone 15 Pro, 16 Pro, 17
+> + 6.46" iPhone 11, 12, 13 & 14 Pro Max
+> + 6.7": iPhone 16 Plus
+> + 6.9": iPhone 16 Pro Max, iPhone 17 Pro Max
+See:
+[support.apple.com/en-gb/guide/iphone/iphe3fa5df43/ios](https://support.apple.com/en-gb/guide/iphone/iphe3fa5df43/ios)
+and
+[wikipedia.org/wiki/List_of_iOS_devices](https://en.wikipedia.org/wiki/List_of_iOS_devices)
+The _full_ device feature compatibility matrix
+lets developers see _exactly_ what features
+are available for all iOS devices (including all iPads):
+https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
+
+## How Many Distinct `Android` Devices
+
+By **2015** there were _already_
+"_more than **24,000 different `Android` devices**
+from **1300 brands**_"
https://www.zdnet.com/article/android-fragmentation-there-are-now-24000-devices-from-1300-brands
+
+
That was before the _explosion_ of new devices from Chinese and manufacturers.
-In 2022 there is no official stat
-for the number of devices or screen sizes
-(_because Google is painfully aware
-of the fragmentation problem
-but doesn't want to surface it!_)
-suffice to say that it's _several_ orders of magnitude
-more complex to build an Android App
+In 2026 there is no official stat
+for the number of devices or screen sizes
+(_because Google is painfully aware
+of the fragmentation problem
+but doesn't want to surface it!_)
+suffice to say that it's **_several_ orders of magnitude**
+**more complex** to **build** an **`Android App`**
that looks _consistently_ good across all devices.
-Android development is _considerably_ more complex,
+Android development is _considerably_ more complex,
which is why devs prefer `iOS` for their MVP.
@@ -277,9 +292,13 @@ and was the 3rd "most loved" framework:
[https://insights.stackoverflow.com/survey/2020#technology-most-loved](https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-other-frameworks-libraries-and-tools-loved3)
-In the 2022 survey `Flutter`
-has overtaken `React Native`
-in popularity:
+In the 2022 survey `Flutter`
+overtook `React Native`
+in popularity:
https://survey.stackoverflow.co/2022/#section-most-popular-technologies-other-frameworks-and-libraries
+and in all years since it has maintained its' lead:
+https://survey.stackoverflow.co/2025
+
[](https://hits.dwyl.com/dwyl/technology-stack)
+